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%tl (57) Abstract: In order to distribute a group message (GN1) in a radio communication network (FN2), a group message (GNI) that 
i3 is to be distributed is sent by at least one multicast center (MCC) to the member- subscriber devices «r a selected group (A) using 
O only one common transmission path (GP) in at least one higher-level radio network control unit (SGSN1 ). The subscriber devices 
(UE1,UE2,UE4,UE5) currently belonging to the corresponding selected group (A) that are to be notified are determined by at least 
O one storage device (SPl) and communicated to the higher-level radio network control unit (SGSN1). 

^ [Fortsetzung auf der n&chsten Seite] 
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® Verfahren zum Vertei.en einer Gruppennachricht in einem Funkkommunikationssystem sow.e zugehonges 
Funkkommunikationssystem 



(51) Zum Verteilen einer Gruppennachricht (GNU in einem 
Funkkommunikationsnetz (FN2) wird durch mindestens 
ein Multicast-Center (MCC) an die Mitglieder-Teilnehmer- 
gerate einer ausgewahrten Gruppe (A) die zu verteilende 
Gruppenachricht (GN1) lediglich auf einem gemeinsa- 
men Ubertragungspfad <GP) an mindestens eine uberge- 
ordnete Funknetzwerkkontrolleinheit (SGSN1) gesendet. 
Dabei werden mittels mindestens einer Speichervornch- 
tung (SP1) die aktuell zugehorigen, zu benach nchti gen- 
den TeilnehmergerSte (UEi; UE2, UE4, UE5) der jeweils 
ausgewahlten Gruppe (A) ermittelt und diesc .der ^uberge- 
ordneten Funknetzwerkkontrolleinheit (SGSN1) mitge- 

"Verteilung von Multicast-Nachrichten im UMTS'. 
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Beschreibung 

Verfahren zum Verteilen einer Gruppennachricht in einem 
Funkkommunikationssystem sowie zugehbriges Funkkom- 

munikationssystem 5 

[0001 J Bci vielen in modernen Mobilfunksystemen ange- 
boicncn Di ens ten und Anwendungen ist es wiinschensweft, 
Nachrichien nicht nur zu einem, sondem zu zwei oder meh- 
rcrcn Mobilfunkicilnchmcm zu iibertragen. Beispiele fiir 10 
sole he Dicnste und Anwendungen sind insbesondere News- 
groups, Videokonferenzen, Video-On-Demand, verteilte 
Anwendungen, usw. 

[0002] Eine Aufgabe der Erfindung ist es, einen Weg auf- 
zuzcigen, wie solche Gruppen-Nachrichten an eine Vielzahl 15 
von Teilnehmergeraten eines Funkkommunikationssy stems, 
insbesondere Mobilfunknetzes, in effizienter Weise ubertra- 
gen werden konncn. Dicsc Aufgabe wird durch folgcndcs 
crtindungsgcmaBc Verfahren gelost: Verfahren zum Vertei- 
len einer Gruppennachricht an mindestens eine Gruppe von 20 
Teilnehnierjieniicn eines Funkkommunikationssystems, wo- 
bei in ntindesiens einer Speichervorrichtung die ein oder 
mehreren leilnchiiicrgerate der jeweiligen Gruppe unter ei- 
ner geineinsarnen Identifizierungsadresse abgelegt worden 
situl unit dor I fori I au fend akluahsiert werden, wobei zur Ver- 25 
icilung der jeweiligen Gruppennachricht durch mindestens 
ein Muhieusi-Centcr an die Mitglieder-Teiinehmergerate ei- 
ner ausgewiihltcn Gruppe diese zu verteilende Gruppen- 
nachrichi lediglich iiber einen gemeinsamen Ubertragungs- 
pfad an mindestens eine iibergeordnete Funknetzwerk-Kon- 30 
trolieinheit gesendet wird, mittels der Speichervorrichtung 
die akiuell zugehbrigen, zu benachrichtigenden Teilnehmer- 
gerate dieser ausgewahlten Gruppe ermittelt, und diese der 
ubergcordnoien Funknetzwerk-Kontrolleinheit mitgeteilt 
werden. und wobei dann von dieser iibergeordneten Funk- 35 
netzwcrk-Kon trolieinheit mindestens ein Ubertragungspfad 
zur Vcncilung der Gruppennachricht an die ermittelten Mit- 
glieds-Tei Inehmergerate der ausgewahlten Gruppe unter Zu- 
hilfenahnic cincr oder mehrerer untergeordneter Funknetz- 
werk-Konirollcinheiien bereitgestellt wird. 40 
[0003] Dadurch ist eine effiziente und einfache Verteilung 
von Gruppen-Nachrichten an die verschiedenen Teilneh- 
mergerate der jcweilig ausgewahlten Gruppe ermoglicht. 
[0004] Die Erfindung betrifft weiterhin ein Funkkornmu- 
nikaiionssysicm zum Verteilen einer Gruppennachricht an 45 
mindestens cine Gruppe von Teilnehmergeraten, insbeson- 
dere nach einem der vorhergehenden Anspriiche, wobei 
mindesiens cine Speichervorrichtung vorgesehen ist, in der 
ein oder mchrere Teilnehmergerate der jeweiligen Gruppe 
unter einer gemeinsamen Identifizierungsadresse ablegbar SO 
und dort fort lau fend aktualisierbar sind, wobei mindesiens 
ein Multicast-Center vorgesehen ist, mitdessen Hilfe bei ei- 
nem Verteilungswunsch eine neue Gruppennachricht an die 
Mitglieds-Teilnehinergerate einer ausgewahlten Gruppe auf 
einem gemeinsamen Ubertragungspfad an mindestens eine 55 
iibergeordnete Funknetzwerkkontrolleinheit sendbar ist, 
wobei die Speichervorrichtung derart ausgebildet ist, dass 
die aktuell zugehbrigen, zu benachrichtigenden Teilnehmer- 
gerate dieser ausgewahlten Ciruppe ermittelbar, und diese 
der iibergeordneten Funknetzwerkkontrolleinheit mitteilbar 60 
sind, und wobei die iibergeordnete Funknetzwerkkontroll- 
einheit und/oder ihre jeweilig in Wirkverbindung stehende 
untergeordnete Funknetzwerkkontrolleinheit derart ausge- 
bildet sind, dass mindestens ein Ubertragungspfad von die- 
ser iibergeordneten Funknctzwcrkkon trolieinheit zur Vcrtci- 65 
lung der Gruppennachricht an die ermittelten Mitglieds- 
Teilnehmergerate bereitstellbar ist. 

[0005] Sonstige Weiterbildungen der Erfindung sind in 



den Unteranspruchen wiedergegeben. 

[0006] Die Erfindung und ihre Weiterbildungen werden 
nachfolgend anhand von Zeichnungen naher erlautert. 
[0007] F.s zeigen: 

[0008] Fig. 1 in schematischer Darstellung die prinzipielle 
Architektur eines Mobilfunksystems, 
[0009] Fig. 2 in schematischer Darstellung den Aufbau ei- 
nes Funkkommunikationssystems, das zur Durchfiihrung 
des erfindungsgemaBen Verfahrens zusatzlich zum Mobil- 
fun ksy stem von Fig. 1 mindesiens ein Multicast-Center zur 
Verteilung von Multicast-Nachrichten auf we ist, 
[0010] Fig. 3 mil 5 in schematischer Darstellung den 
schrittweisen Aufbau eines PDP-Contextes, wenn fiir ein 
bestimmtes Teilnehmergerat des Funkkommunikationssy- 
stems nach Fig. 1 bzw. 2 ein Datenpaket netzwerkseitig 
ubermittelt werden soil, 

[0011] Fig. 6 in schematischer Darstellung verschiedene 
Pakctwcgc im Funkkommunikationssystem nach Fig. 1 fur 
mehrere zu benachrichtigende Teilnehmergerate, an die 
diesselbe Nachricht nach Aufbau von Ubertragungsverbin- 
dungen entsprechend den Fig. 3 mit 5 jeweils einzeln uber- 
mittelt wird, 

[0012] Fig. 7 in schematischer Darstellung Pakei wege im 
erfindungsgemaBen Funkkommunikationssystem nach Fig. 
2 bei Anwendung des Uberlragungswegaufbaus enLspre- 
chend den Fig. 3 mit 5 fur das Mobilfunksystem nach Fig. 1, 
[0013] Fig. 8 mit 10 in schematischer Darstellung den 
schrittweisen Aufbau von Ubertragungsverbindungen zur 
Ubertragung von Multicast-Nachrichten an eine ausge- 
wahlte Gruppe von Teilnehmergeraten nach einer ersten Va- 
riante des erfindungsgemaBen Verfahrens mit Hilfe des 
Funkkommunikationssystems nach Fig. 2, 
[0014] Fig. 11 in schematischer Darstellung den detaillier- 
ten Ablauf eines Verbindungsaufbaus fur ein einzelnes Teil- 
nehmergerat nach dem erfindungsgemaBen Verfahren ent- 
sprechend den Fig. 8 mit 10, 

[0015] Fig. 12 in schematischer Darstellung eine weitere 
Variante des erfindungsgemaBen Verfahrens, 
[0016] Fig. 13 in schematischer Darstellung den detail- 
lierten Verbindungsaufbau fiir ein bestimmtes Teilnehmer- 
gerat, 

[0017] Fig. 14 in schematischer Darstellung den Regi- 
strierungsprozess eines Teilnehmergerats im Funkkommu- 
nikationssystem nach Fig. 2, um eine Multicast-Nachricht 
nach dem erfindungsgemaBen Verfahren empfangen zu kbn- 
nen, 

[0018] Fig. 15 in schematischer Darstellung die Kompo- 
nenten einer Packlet Switched Domaine, die beim Transport 
von Paketdaten im UMTS-Network beteihgt sind, 
[0019] Fig. 16, 17 schematisch das prinzipiellen Verfah- 
ren zur Verteilung von Gruppennachricht en nach dem Inter- 
net Group Managment Protokoll, 

[0020] Fig. 18 schematisch das prinzipielle Verteilungs- 
verfahren fiir Gruppennachrichten nach dem Reverse Path 
Multicasting Prinzip, 

[0021] Fig. 19 in schematischer Darstellung die Signali- 
sierung fiir ein bestimmtes Teilnehmergerat zum Eintrag sei- 
ner Multicast-Gruppenzugehorigkeit in eine Datenbank zur 
Durchfiihrung des erfindungsgemaBen Verfahrens mit dem 
Funkkommunikationssystem nach Fig. 2, 
[0022] Fig. 20 in schematischer Darstellung eine erste Va- 
riante einer Multicast-Context Aktivierung zur Verteilung 
von Multicast-Nachrichten nach dem erfindungsgemaBen 
Verfahren mil Hilfe des Funkkommunikationssystems nach 
Fig. 2, 

[0023] Fig. 21, 22 jeweils in schematischer Darstellung 
modifizierte Multicast-Context Akdvierungen zur Durch- 
fiihrung des erfindungsgemaBen Verfahrens, 
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[0024] Fig. 23 mil 25 drei verschiedeDe Varianten ties er- 
findungsgema&en Multicast- Vcrfahrcns zur Vcrtcilung von 
MulucasLNachrichten, 

[0025] Fig. 26 eine Varianie des Multicast- Verfahrens 
nach Fig. 23 

[0026] Fig. 27 eine Variante des Multicast- Verfahrens 
nach Ftg. 24, und 

[0027] Fig. 28 eine Variante des Multicast- Verfahrens 
nach Fig. 25. 

[0028] Elemente mit gleicher Funktion und Wirkungs- 
weise sind in den Fig. 1 mit 28 jeweils mit denselben Be- 
zugszeichen versehen. 

|0029] In modemen Mobilfunksystemen wie z. B. nach 
dem UMTS (Universal Mobil Communication System), 
GPRS (General Paket Radio Service), EDGE (Enhanced 
Data Rates for GSM Environment) ist es wiinschenswert, 
Nachrichten nicht nur zu einem einzelnen, sondern zu zwei 
odcr mchrcrcn Mobilfunktcilnchmcrn zu ubcrtragen. Bci- 
spiclc fur solche Dienste und Anwendungen sind News- 
Groups. Video-Konferenzen, Video-On-DemanD, verteilte 
Anwendungen usw. 

|0030) Bei der Ubertragung der Nachrichten zu den ver- 
schicdcncn Teilnehmem ist es moglich. jedem Empfanger 
scparai eine Kopie der Daten zuzusenden. Diese Vorgehens- 
wcisc isi zwar einfach zu implemenueren, fur groBe Grup- 
pen von Teilnehmergeraten jedoch zu aufwendig. Da die 
sclbc Nachricht iiber N (N = Anzahl der Empfanger der 
Nachricht) Einzelverbindungen (= Unici^'-Verbindungen) 
ubcrtragen und dabei mehrfach iiber gei ;nsame Verbin- 
dungswege gesendet wird, benotigt di ses rfahren eine zu 
hohc Bandbreite. 

[ 003 1 ] Eine bessere Moglichkeir bn _*t demgegeniiber die 
sog. Multicasi-Ubertragung. Hie: ei warden die verschiede- 
ncn Tcilnchmergerate, denen die sulbe Nachricht ubermittelt 
werden soil, zu einer Gruppe (= Multicast-Gruppe) zusam- 
mengefasst und dieser eine gemeinsame Identifizierungs- 
adrcsse (Multicast-Adresse) zugeordnet. Auf diese Vfeise ist 
es nicht erforderlich. dass der jeweilige Sender weiB, wie 
viele und welche Empfanger sich hinter der Multicast- 
Adresse verbergen. Es ist vielmehr ausreichend fiir den je- 
wel ligen Sender, lediglich den Namen bzw. die Adresse der 
zu benachrichtigenden Multicast-Gruppe zu kennen. Die zu 
ubertragenden Daten werden daraufhin nur einmal an diese 
Multicast-Adresse versendet. 

[0032] Problem atisch fiir das Verteilen solcher Mulucast- 
Nachrichten ist hierbei allerdings insbesondere die Verwal- 
tung der Multicast-Gruppen so wie die Wegwahl (= Routing) 
der Multicast-Nachrichten zu den einzelnen Teilnehmerge- 
raten der Multicast-Gruppen. Die Erfassung der zu einer 
Multicast-Gruppe gehorenden Teilnehmer ist insbesondere 
irn Hinblick darauf problematisch, dass zu jedem Zeitpunkt 
neue Teilnehmergerate zu dieser Multicast-Gruppe beitre- 
ten, aber auch Mitglieder der jeweiligen Multicast-Gruppe 
wieder austreien konnen. 

[0033] Im Rahmen der Erfindung wird beispie[haft im fol- 
genden auf die Komponenten der packetswitched Domain 
eine UMTS-Mobilfunknetzes FN1 eingegangen. Die Funk- 
tion und Wirkungsweise dessen Komponenten werden 
nachfolgend anhand von Fig. 15 naher erlautert: 
Ein Teilnehmer-Endgerat wie z. B. UE (User Equipment) ist 
iiber eine Luftschnittstelle Uu (Uu-Interface) mit einer Ba- 
sissiation Node B verbunden. Diese Node B ist iiber eine 
Festnetzverbindung Iub mit einem RNC (Radio Network 
Controller) als erste Funknetzwerkkontrolleinheit verbun- 
den, die die Rcssourccn der Luftschnittstelle kontrollicrt 
und verteilL Der RNC wiederum kann eine oder mehrere 
Basisstationen versorgen. Das Teilsystem aus mi n des tens ei- 
nem Radio Network Controller und entsprechend zugehori- 



gen Basisstationen wird im ailgemeinen als Radio Network 
Subsystem RNS bezeichnet, was in der Figur gestrichelt 
umrahmt angedeutet isL Fiir die paketvermittelte Uberira- 
gung von 7.. B. TP-Paketen aus dem Internet TP zu einem ein- 
zelnen Teilnehmergerat wie z. B. UE ist mindestens einer 
der Radio Network Controller wie z. B. RNC iiber eine Fest- 
netzverbindung Iu mit einer hoheren Funknetzwerkkontroll- 
einheit SGSN, insbesondere im UMTS-Standard mit einer 
sog. Serving GPRS Support Node, verbunden. Fiir eine 
to Ubertragung von Daten aus einem fremden Paketdatennetz, 
wie hier beispielsweise dem Internet IP, ist die ubergeord- 
nete Funknetzwerkkontrolleinheit SGSN vorzugsweise iiber 
eine Festnetzverbindung Gn mit mindestens einem Gateway 
GGSN. insbesondere einem Gateway GPRS Support Node, 
15 verbunden. Dieses Gateway GGSN realisiert den Zugangs- 
punkt zu einem fremden Paketdatennetz. Uber eine Fest- 
netzverbindung Gi ist hier im Ausftihrungsbeispiel von Fig. 
15 das Gateway GGSN mit cincm Scrvcrr im Internet IP 
verbunden. Informationen fur das Managment der mobilen 
20 Teilnehmer konnen von Gateway GGSN iiber eine Festnetz- 
verbindung Gc und von der hoheren Netzwerkeinheit SGSN 
uber eine Festnetzverbindung Gr von einer zentral gefuhrten 
Datenbank HLR insbesondere dem sog. Home Location Re- 
gister abgefragt werden. Die hohere Funknetzwerkkontroll- 
25 einheit SGSN erfragi vom Home Location Register HLR 
nutzerspezifische Informationen wie z. B. zur Authentifizie- 
rung eines Teilnehmers. Desweiteren ist die hohere Kon- 
trolleinheit SGSN vorzugsweise verantwortlich fur einen 
Verbindungsaufbau zwischen dem jeweiligen Teilnehmer- 
30 gerat und einem fremden Paketdatennetz wie hier z. B. IP. 
[0034] Sollen Paketdaten aus dem externen Paketdaten- 
netz zum Funknetzwerk iibertragen werden, so gel an gen 
diese zuerst zum Gateway GGSN, das beim Home Location 
Register HLR die jeweilig zustandige hohere Funknetz- 
3S werk-KontroUeinheit SGSN erfragL Dieser Gateway GGSN 
teilt nun der hoheren Funknetzwerk-Kontrolleinheit SGSN 
mit, dass Daten fiir das entsprechende Teilnehmergerat vor- 
liegen. Die hoherer Funknetzwerk-Kontrolleinheit SGSN 
veranlasst daraufhin den Aufbau der Verbindungen zwi- 
40 schen dem zu benachrichtigenden Teilnehmergerat UE und 
dem externen Netzwerk IP. 

[0035] Im Rahmen der Erfindung wird dabei unter einem 
Teilnehmergerat (User Equipment) als Komponente eines 
Funkkommunikationssy stems vorzugsweise ein mobiles 

45 Endgerat verstanden. Dieses ist z. B. im UMTS-Standard 
insbesondere liber die Luftschnittstelle Uu (Uu-Interface) 
mit dem sog. UTRAN (UMTS Terrestrial Radio Access 
Network) verbunden. Es enthalt das UMTS Subscriber 
Identity Modul (USIM), indem (ahnlich wie in der SIM im 

50 GSM-Netz) Identifizierungsdaten, die das Teilnehmergerat 
zur Registrierung und Teilnahme im UMTS-Netz berechti- 
gen, gespeichert sind. 

[0036] Eine Basisstation (Node B) ist eine Funknetzwerk- 
Komponente, die fur die Versorgung einer bzw. mehrerer 
55 Funkzellen zustandig ist. Mittels einer Basisstation erfolgt 
die Funkkommunikation iiber die Luftschnittstelle mit dem 
jeweiligen Teilnehmergerat in derFunkzelle dieser Basissta- 
tion. 

[0037] Unter Radio Network Controller wird im Rahmen 
60 der Erfindung eine erste, untergeordnete Funknetzwerk- 
Kontrolleinheit verstanden, mit deren Hilfe die Ressourcen 
der Luftschnittstelle zwischen der jeweiligen Basisstation 
und den etwaigen Teilnehmergeraten in deren Funkzelle 
kontrolliert wird. Ein Radio Network Controller versorgt 
65 und kontrollicrt vorzugsweise cin odcr mchrcrc Basissta- 
tionen. Das Teilsystem aus einem Radio Network Controller 
wie z. B. RNC in Fig. 15 und einem oder mehreren Basissta- 
tionen wird als Radio Network Subsystem RNS bezeichnet, 
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was in der Fig. 15 durch eine gestrichelte Umrahmen ange- 
deutet ist. Dieses Teilsystem ist durch das Iu-Interface mil 
mindesiens einer hoheren Netzwerkkontrolleinheit wie z. B. 
SGSN in Fig. 15 verbunden. 

[00381 GPRS Support Nodes wie z. B. SGSN bilden die 5 
Schnittstelle zwischen dem Funk system und einem Festnetz 
fiir vorzugsweise paketvertnitieke Services (PDN). Ein 
GPRS Support Node fiihrt alle notwendigen Funktionen 
aus, um den Transport von Da ten pake ten vom extemen 
PDN zum End-Teilnehmergerat, insbesondere zur Mobilsta- 10 
tion, und umgekehrt zu gewahrleisten. Z. B. im UMTS- 
(JPRS-Netzwerk gibt es vorzugsweise 2 verschiedene 
GPRS Support Nodes (GSNs): den SGSN (Serving GSN) 
und den GGSN (Gateway GSN). 

[0039] Der SGSN ist derjenige Knoten, der die Teilneh- 15 
mergerate. insbesondere Mobilfunkstationen einer ihm zu- 
geordneten Region (SGSN Area) versorgt. Er verfolgt den 
Aufcnthalisort dcs jcwciligcn Tcilnchmcrgcrats, fiihrt Si- 
cherhe its funktionen und Zugriffskontrollen aus (Authenti- 
cation, cipher setting procedures und ahnliches). Ein SGSN 20 
besitzt Routing/Traffic-Managment-Funktionen und reah- 
siert die Schnittstelle zum GGSN (Gn) Access Network 
(Gb) und zu anderen PLMNs (Gp) (public land mobile net- 
works). Die Location Register Funktion des SGSN speichert 
neben den Teilne Inner Regisirierungsinformauonen (TMSI, 25 
temporare Identitiiten, PDP Adressen (packet data protocol) 
auch sogenannte Location Informationen, die benotigt wer- 
den. um eine Pake Ida teniibertragung aufzubauen bzw. zu 
beenden. 

[0040] Die Location Information kann je nach Modus der 30 
Mobilstation (MS) entweder die Cell- oder die Routing- 
Area sein, wo die MS derzeit registriert ist. Desweiteren 
werden aber auch die VLR-Nummer des verbundenen VLR 
(visitor location register) und die Adressen jedes GGSN ge- 
speichert, fiir den ein aktiver PDP Context (siehe untenste- 35 
henden Abschnitt "Ubertragung von Paketdaten im UMTS") 
besteht. 

[0041] Desweiteren steuert der SGSN das Mobility Ma- 
nagement (mm), das genutzt wird, um den aktuellen Aufent- 
h alts on einer MS zu bestimmen. Auf der gleichen Protokoll- 40 
ebene zum Mobility Management existiert das Session Ma- 
nagement (SM), welches fiir die Aktivierung und Deaktivie- 
rung des eben genannten PDPContextes im SGSN sowie im 
GGSN zustandig ist. 

[0042] Uber das Gr-Interface tauschen SGSN und HLR 45 
Informationen aus. 

[0043] Der GGSN ist der Knoten, der den Kontakt (Inter- 
working) zwischen einem UMTS PLMN und einem Paket- 
daten Netzwerfc (PDN) ermoglicht. Die Datenaustausch er- 
folgt uber das Gi-Interface (Fig. 15). Der GGSN beinhaltet 50 
die Routing Informationen fur die im PLMN erreichbaren 
UMTS Teilne hmer. Die Routing Informationen dienen der 
Kontaktierung des jeweiligen SGSN, in dessen Versor- 
gungsbereich (SGSN Area) sich eine bestimmte MS mo- 
men tan betindet. Um diesen SGSN zu kontaktieren, wird 55 
dessen Adresse als Location Information zweckmaBiger- 
weisc gespeichert. 

[0044] Aufenthaltsinformationen uber eine MS konnen 
uber das Gc-Interface vom HLR abgefragt werden. 

60 

Home Location Register (HLR) 

[0045] Das HLR besteht aus einer Da ten bank, die fur das 
Management der mobilen Teilnehmer verantwortlich isL 
Ein PLMN (Public Land Mobile Network) kann cin odcr 65 
mehrere HLRs beinhalten. Dies ist abhangig von der Anzahl 
der mobilen Teilnehmer, der Kapazitat des Equipments und 
von der Organisation des Netzwerkes. Die folgenden Arten 
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von Informationen werden hier gespeichert: 

- Anmeldungsinformationen der Teilnehmer 

- Einige T vocation Informationen emioglichen die Ab- 
rechnung und das Routing von Gesprachen zu dem 
MSC (Mobile-services Switching Center), bei dem die 
MS (Mobile Station) registriert ist (z. B. die MS Roa- 
ming Number, die VLR (Visitor Location Register) 
Number, die MSC Number, die Local MS Identity). 

[0046] Sofem GPRS unterstutzt wird, werden Location 
Informationen gespeichert, die die Abrechnung und das 
Routing von Nachrichten im SGSN (Serving GPRS Support 
Node) ermoglichen, an dem die MS gegenwartig angemel- 
det ist (z. B. die SGSN Number). Unterschiedliche Typen 
von Identifizierungen sind mit jeder Anmeldung einer MS 
verbunden und werden im HLR gespeichert: 

- International Mobile Subscriber Identity (IMSI) 

- Eine oder mehrere Mobile Station International 
ISDN numbers (MSISDN) 

- Keine, eine oder mehrere Packet Data Protocol 
(PDP) Adressen (TP Adressen) 

[0047] Es wird iiiuner mindesiens eine Identital, geirenni 
von der IMSL mit einer MS Anmeldung ubergeben und im 
HLR gespeichert. Die IMSI oder die MSISDN konnen als 
Kennung fur den Zugang zu den Informationen des HLR fur 
die "mobile Anmeldung" genutzt werden. Die HLR-Daten- 
bank enthalt auch anderc informationen, wie z, B.: 

- Teleservices und Ubermittlerservices, Anmeldein- 
formationen 

Serviceeinschrankungen (z. B. begrenztes Roaming) 

- eine Liste aller Gruppen IDs, welche die Teilnehmer 
zum Aufbau einer Voice Group oder eines Broadcast 
Calls berechtigen 

- Informadonen daruber, wenn es einem GGSN (Gate- 
way GPRS Support Node) erlaubt ist, dynamisch ei- 
nem Teilnehmer eine PDP Adresse zuzuweisen 

- Optional zusatzliche Services 



Home Subscriber Server (HSS) 

[0048] Das HSS enthalt LCS subscription data und Rou- 
ting-! nformationen. Fiir umherschweifende (roaming) UEs 
kann das HSS in verschiedenen PLMNs sein. 
[0049] Dieses Netzwerkelement ist eine Erweiterung des 
HLR fur das zukiinftige All-IP-Netzwerk. 
[0050] Bevor Paketdaten (hier im Ausfuhrungsbeispiel 
IP-Pakete) zwischen beispielsweise einem Server im Inter- 
net IP und einem End-Teilnehmergerat wie z. B. UE (ver- 
gleiche Fig. 15) ubertragen werden konnen, wird vom Teil- 
nehmergerat UE zweckmaBigerweise ein sog. PDP Context 
(Paket Data Protokoll Context) aufgebaut, mit dessen Hilfe 
eine Verbindung zum Internet IP hergesteLlt wird. Ein PDP 
Context beschreibt dabei den Pfad durch das jeweilige Netz- 
werk, insbesondere UMTS-Netzwerk, und macht diesen in 
den Netzelementen UE, SGSN, GGSN be kann t. Erst darauf- 
hin kann eine Verbindung aufgebaut werden, uber die dann 
die Paketdaten (im UMTS IP-Pakete) ubertragen werden. 
[0051] Im Rahmen dieser Erfindung wird haufig der Be- 
griff Bearer verwendet. Allgemein beschreibt der Begriff 
Bearer (Tragcr) cincn Pfad zur Ubertragung von Informatio- 
nen. Dieser ist insbesondere definiert durch seine Kapazitat, 
Laufzeitverzogerung und Bitfehlerrate. Die Schnittstelle 
zwischen dem jeweiligen Radio Network Subsystem RNS 
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und sog. Core-Network (CN) wird als EU-Inierface bezeicb- 
nct. Das Core- Network ist dabei durch cine gestrichelte Urn- 
rahmung in der Fig. 15 angedeuteL Der Informationspfad 
-/.wischen dem RNS und dem CN wird dahei insbesondere 
RU-Bacrer genannt Ein Radio-Bearer ist vorzugsweise der 5 
Service fur den Transfer von Nutzerdaten zwischen dem je- 
weiligen Teilnchmergerat UE und UTRAN (UMTS Terre- 
sirial Radio Access Network). 

1 0052 1 Insbesondere im UMTS-Funkkomrnunikationssy- 
sicm sowie wciteren Funkkomrnunikationssystemen wie 10 
z. B. nach deni GPRS, EDGE, OFDM (Orthogonal Fre- 
quency Division Multiplexing) Prinzip sind Multicast-Ser- 
vices /.ur Verteilung von Multicast-Nachrichten von Inter- 
essc. 

[0053] Bishcr werden lediglich im Internet Multicast- 15 
Die n sic angeboten. d. h. auf der Festnetzseite. Ein solcher 
Dicnsi is i bcispielswcise das IP Multicast. Das international 
genonnic Inicmct-Proiokoll (IPV6) bictct die Moglichkcit 
der sog. Muliicasi-Adressienmg, iiber die Informationen 
zwischen Gruppen von Rechnern (oder g arizen Subnetzen) 20 
ausgeiauschi werden konnen. Die Empfangergruppe, auch 
Multicasi-Gruppe genannt, wird mit einer eindeutigen IP- 
Adrcssc (Muliica-si-Adrcssc) angesprochen, wobei der Sen- 
der die /.usaminensei/.ung der Gruppe, z. B. Mitgliederan- 
zahl und A u lcm hall sort nichi kennL. Einzelne Hosts, insbe- 25 
sonde rc Rechner konnen jederzeit einer Gruppe beitreten 
und sic wi oiler vcrlassen. Ein Host kann Mitglied in mehre- 
ren Gruppen sein. Um an cine Gruppe Daten zu senden. ist 
es nicht erlbrdcrlich. dass der Sender zwingend Gruppen- 
mitglicd isi. Fur die Vcrwaltung von Multicast-Gruppen und 30 
die Weg wahl (Routing) der Nachrichlen zu den Teifnehmem 
einer IP Multicast-Gruppc gibt es im Internet unterschiedli- 
che Algoriilimcn b/.w. Protokolle. 

Intcrnei-Group-Managment-Protokoll (IGMP) 35 

[0054] Dieses Protokoll ermoglicht eine Multicast-Router 
(MC-Rouicr) wic •/.. B. IPR von Fig. 16 Gruppenzugehorig- 
keiten einzclner Rcchncr wie z. B. HI mit HN abzufragen. 
Es gibt eineni ITosi die Moglichkeit, auf soich eine Anfrage 40 
RQ alle seine Milgliedschaften anzuzeigen. Das Internet- 
Group- Managnicni-Proiokoll IGMP Version 1 kann zwei 
Arten von Meldungcn versenden. Die eine nennt sich Host 
Membership Query (Typ = 1) und die andere Host Member- 
ship Report (Typ = 2). Ein Muliicasi-Router wie z. B. EPR 45 
von Fig. 16 infonnicrt sich in seinem Zustandigkeitsbereich 
(Subnetz) iiber die anwesenden Gruppenmitglieder wie z. B. 
HI mil HN. Dies crrcicht er durch die Aufforderung RQ an 
alle Hosts, ihrc Gruppenzugehorigkeii bekannt zu geben 
(Host Membership Query). Solche Querys werden vorzugs- 50 
weise in periodischen Absiiinden erzeugl. damil sich der 
Router IPR auf Vcrandcrungen einstellen kann. Damit diese 
Nachricht alle Hosts erreicht, wird diese an die Gruppe aller 
Hosts im Subnetz gesendet. Nach Erhalt dieses Querys ant- 
wortet jeder Host fur jede Gruppe. in der er Mitglied ist, mit 55 
einem Host Membership Report RE, was in der Fig. 17 ver- 
anschaulicht ist. Er gibt dem Multicast-Router IPR damit 
bekannt, dass er Mitglied dieser Gruppe ist. IGMP Version 2 
bietet Hosts die Moglichkeit. dem MC-Router beim Verlas- 
sen einer MC-Gruppe eine Leave-Nachricht zu zusenden, 
um so unnotigen Verkehr zu vermeiden. Desweiteren kon- 
nen gruppen spezifische Querys versendet werden, was be- 
deutet, dass nicht immer alle Gruppenzugehorigkeiten abge- 
fragi werden, sondem vorzugsweise immer nur Bestimmte. 

Reverse Path Multicasting (RPM) 

[0055] Ein Algorithmus, der Multicast-Nachrichten vom 



Sender Uber ein Netz (z. B. Internet) bis zu den Empfangem 
vcrteilt, ist das sog. Reverse Path Multicasting. Dessen 
Grundprinzip ist schematisch in der Fig. 18 veranschaulicht. 
Beim RPM-Verfahren wird ein erstes Datenpaket (einer 
Mulucast-Nachrichi) eines Senders iiber das ganze Netz 
verteilL Bekommt nun ein Blattrouter (Multicast Router, der 
keine weileren Verbindungen zu anderen Routern hat) ein 
Paket einer Gruppe, fur die er keine Mitglieder in seinem 
Subnetz hat (was er beispielsweise mit Hilfe von IGMP er- 
fragt hat), so sendet er an seine Vorg anger eine sog. Prune 
Nachricht wie z. B. PRN. Damit teilt er seinem Vorganger 
mit, dass er zukunftig Daten dieser Gruppe nicht mehr beno- 
tigL Falls nun ein Router auf alien seinen child links (Ver- 
bindungen zu anderen Routern, auBer die, iiber die er die 
Nachricht bekommen hat) Prune Nachrichten erhalt und in 
seinem eigenen Subnetz auch keine Mitglieder fur diese 
Gruppe vorhanden sind. so gibt auch er an seine Vorganger 
cine Prune Nachricht fur dicsc Gruppe wcitcr. So mil bc- 
schrankt sich die Verteilung der Daten auf Pfade, die zu 
Gruppenmitghedem fuhren. Bezogen auf Fig. 17 bedeutet 
dies, vorausgesetzt im Subnetz von Router E und F befinden 
sich keine Mitglieder der betrachtenden Gruppe, dass keine 
Daten vom Router B nach Router E gesendet werden. Um 
jedoch zu iiberprufen, ob in einem durch Prune Nachrichten 
verkiirzlen Teilbaum ein Host einer Gruppe beigetreien ist, 
ist es zweckmaBig, in periodischen Abstanden Daten wieder 
iiber das ganze Netz zu senden. Jeder Router pro Gruppe 
speichert vorzugsweise Daten daruber. an welchen Router er 
Pakete weitergeben darf und an welche nicht. 
[0056] Um nun fur ein Funkkommunikationsnetz, insbe- 
sondere fur ein UMTS und/oder GPRS Mobilfunksystem, 
eine ef&ziente Verteilung von Multicast-Nachrichten zu er- 
moglichen, wird vom Grundkonzept her belrachtet zweck- 
mafiigerweise ein Eintrag der Multicast-Gruppenzugehorig- 
keit in mindestens eine Datenbank. das Bekanntmachen der 
Multicast-Gnippenteilnehmern in den Netzwerkelementen 
des Funkkommunikationsnetzwerks (Multicast-Context ac- 
tivation) und/oder die Obertragung einer Mulucast-Nach- 
richt von der jeweiligen Nachrichtenquelle wie z. B. einem 
Multicast-Sender bis zur Nachrichten senke wie z. B. dem 
End-Teilnehmergerat einer Multicast-Gmppe vorgenom- 
men. Im Rah men der Erfindung wird haufig das sog. Multi- 
cast-Center erwahnt. Diese zusatzliche Komponente ist fur 
das Generieren von Multicast-Nachrichten zustandig. 
[0057] Mit Hilfe dieser prinzipieUen Einfuhrung einer Da- 
tenbank fur den Eintrag der Multicast-Gruppenzugehorig- 
keiten sowie der Funktionalitatserweiterung der bereits be- 
stehenden Funknetzwerkkomponenten um die Fahigkeit, 
Multicast-Nachrichten erkennen zu konnen, ist eine einfa- 
che und effiziente Verteilung von Multicast-Nachrichten im 
jeweiligen Funkkommunikationssystem ermoglicht. Weiter- 
hin ist eine effiziente Anbindung an exteme Festnetze er- 
moglicht, die insbesondere paketorientien arbeiten. 
[0058] Fig. 1 zeigt in schemaiischer Darstellung die 
grundsatzliche Architektur eines UMTS-Funkkommunika- 
tionssy stems. Nicht gezeigt ist dabei der Ubersichtlichkeit 
halber das sog. Home Location Register HLR als Daten- 
bank, die eine Verbindung zu SGSN und GGSN hat, wie 
dies in Fig. 15 dargestellt ist. Eben falls weggelassen ist das 
sog. Visitor Location Register VLR. das mit dem Home Lo- 
cation Register HLR verbunden ist. In einem solchen Funk- 
netzwerk FN1 entsprechend Fig. 1 bildet der GGSN den Zu- 
gang fur exteme Netze EN zum UMTS-Funknetz. Am Gate- 
way GGSN sind iiblicherweise mehrere ubergeordnete 
65 Funknctzwcrk-Kontrollcinhcitcn wic z. B. SGSN1 mit 
SGSGN3 iiber zugehorige Datenverbindungen LUG mit 
LI3G angekoppelL Diese Kontrolleinheiten SGSN1. 
SGSN2 sowie SGSN3 sind vorzugsweise fiir den Verbin- 
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dungsaufbau im Funknetz FN1 verantwonlich, Jede hSherc 
Funknetzwerk- Kontrolleinheit wic z. B. SGSN1 mit SGSN3 
steht wiederum iiber Datenverbindungen wie z. B. Oil, 
U21, TJ31, U202, TJ503 mit untergeordneten Funknety.- 
werk-Kontrolleinheit RNC1, RNC2, RNC3, RNC20 sowie 
RNC50 in Wirkverbindung. Diese uniergeordneten Funk- 
neizwerkeinheiten werden im UMTS -Standard mit Radio 
Network Controller bezeichnet. Diese verwalten jeweils die 
Ressourcen auf der Luftschnitts telle und stellen die Teilver- 
bindung zwischen dem jeweiligen RNC und dem End-Teil- 
nehmergerat her. Jedem Radio Network Controller sind ein 
oder mehrere Basisstationen zugeordnet. die iiber jeweils 
mindestens eine Luftschnittstelle die Funkverbindung zu ein 
oder mehreren Teilnehmergeraten in ihrer jeweiligen Funk- 
zelle bereitstellen. 

10059] Im Einzelnen ist an die erste hohere Funknetz- 
werk-Kontrolleinheit SGSN1 eine Gruppe von 3 unierge- 
ordneten Kontrollcinhcitcn, insbesonderc Radio Network 
Controller RNC1, RNC2, RNC3 iiber entsprechende Daten- 
verbindungen LI11, LI21, LI31 angekoppelt. Die hohere 
Funknetzwerk-Kontrolleinheit SGSN2 steht in der Fig. 1 le- 
diglich mit der einzelnen untergeordneten Kontrolleinheit 
RNC20 iiber die Datenleitung LI202 in Wirkverbindung. 
Mit der hoheren Netzwerkeinheit SGSN3 ist ebenfalls ledig- 
lich ein einzelner Radio NeLwork Controller RNC50 iiber 
eine Datenleitung LI503 verbunden. An den ersten Radio 
NuMwork Controller RNC1 sind in der Fig. 1 die beiden Ba- 
sisstationen BS11, BS12 iiber zugehorige, separate Daten- 
verbindungen LI 111*, Li 121* angekoppelt. Im Bereich der 
Funkzellen dieser beiden Basisstationen BS11, BS12 halten 
sich dabei dabei die beiden Teilnehmergerat UE4 und UE5 
auf. Dem zweiten Radio Network Controller RNC2. der 
ebenfalls an derselben hoheren Funknetzwerk-Kontrollein- 
heit SGSN1 hangt. sind ebenfalls 2 Basisstationen BS21, 
BS22 iiber entsprechende separate Datenverbindungen 
LI212*. LI222* zugeordnet. Im FunkzeUenbereich der Ba- 
sisstation BS22 befindet sich dabei im Ausfiihrungsbeispiel 
von Fig. 1 aktuell das Teilnehmergerat UE1. Der dritte Ra- 
dio Network Controller NNC3, der iiber die Datenverbin- 
dung LI31 ebenfalls mit der hoheren Kontrolleinheit 
SGSN1 gekoppeh ist, versorgt schlieBlich die Basisstation 
BS31 iiber eine Datenverbindung LI313*. In der Funkzelle 
dieser Basisstation BS31 halt sich beispieihaft das Teilneh- 
mergerat UE2 auf. 

[0060] Die 4 Teilnehmergerat UE1, UE2, UE4, UE5 sol- 
len nun als Multicast-Gruppe A vom extemen Netzwerk EN 
eine Multicast Nachricht moglichst effektiv empfangen kon- 
nen. Dazu wird den Komponenten des Mobilfunknetzes 
eine erweiterte Funktionalitat gegeben sowie zusatzlich 
mindestens ein sog. Multicast-Center eingefiihrt. Fig. 2 
zeigt ein derart gegeniiber Fig. 1 modifiziertes Funknetz- 
werk FN2 insbesonderc fur den UMTS-Standard. Das Mo 
bilfunknetz FN2 weist als zusatzliches logisches Netzwerk- 
element gegeniiber dem Funknetz werk FN1 von Fig. 1 das 
Multicast-Center MCC auf. Es ist iiber separate Datenver- 
bindungen wie z. B. LI1C, LI2C, LI3C mit alien hoheren 
Funknetz werk- Kontrolleinheiten, hier im UMTS insbeson- 
derc Serving GPRS Support Nodes wie z. B. SGSN1, 
SGSN2, SGSN3 verbunden. Dabei konnen Nachrichten wie 
in einem EP-Festnetz iiblich, auch iiber mehrere Netzwerk- 
knoten zu den einzelnen Serving GPRS Support Nodes ge- 
langen. Die Funktionalitat des Multicast-Centers umfasst 
dabei insbesonderc die Verwaltung der fur das UMTS Mo- 
bilfunknetz zur VerfOgung gestellte Multicast-Gruppen. 
d. h. allc zur Vcrfugung ges tell ten Multicast-Gruppcn und 
deren Identitaten sind zur Adressierung im Multicast- Sender 
gespeichert und dort somit bekannt Die Speicherung der 
Multicast-Gruppen ist in der Fig. 2 beispieihaft dadurch ver- 
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anschaulicht, da6 das Multicast-Center MCC iiber eine ge- 
strichelt gezeichnete Datenleitung K04 mit einer externen 
Speichervorrichtung SP1 verbunden ist. Ebenfalls der Ser- 
ving GPRS Support Node SGSN1 ist iiber eine Datenver- 
5 bindung KOI mit der Speichervorrichtung SPl verbunden 
und hat somit Zugriff auf deren Dalenbestande. In dieser 
Speichervorrichtung SPl ist unter einer gemeinsamen Iden- 
tifizierungsadresse IDA die Multicast-Gruppe A abgelegt, 
die im Ausfiihrungsbeispiel von Fig. 2 aktuell die Teilneh- 
io mergerate UE1, UE2, UE4 und UE5 umfasst. In entspre- 
chender Weise dazu sind in der Speichervorrichtung SPl 
auch die Identifizierungsadressen wie z. B. EDB fur weitere 
Multicast-Gruppen abgespeichert. Mit dieser Speichervor- 
richtung SPl sind vorzugsweise auch alle anderen hoheren 
15 Funknetzwerk-Kontrolleinheiten, insbesonderc Serving 
GPRS Support Nodes verbunden. In der Fig. 2 ist im einzel- 
nen der Serving GPRS Support Node SGSN2 iiber eine Da- 
tenverbindung K02, sowie der Support Node SGSN3 iiber 
eine Datenverbindung K03 an die Speichervorrichtung SPl 
20 angekoppelt. Die Speichervorrichtung SPl wird also vor- 
zugsweise als zentral gefuhrte Datenbank betrieben. Selbst- 
verstandlich kann es auch zweckmaBig sein, mehrere solche 
Speichervorrichtungen im Funknetz FN2 vorzusehen. Die 
Daten verwaltung der Multicast-Gruppen wird dabei eben- 
25 falls zweckinaBigerweise zentralisiert als eine logische Ein- 
heit vorgenommen. 

[0061] Gegebenenfalls kann es auch zweckmaBig sein, 
solche Speichervorrichtungen zum Ablegen der Identifizie- 
rungsadressen fiir die Multicast-Gruppen sowie deren spezi- 
30 fischen Teilnehmereintrage nicht als exteme, eigenstandige 
Komponenten im Netz zu installieren, sondern im Multi- 
cast-Center selbst sowie in der jeweiligen hoheren Funk- 
netzwerk-Kontrolleinheit, insbesonderc im jeweiligen Ser- 
ving GPRS Support Node zu integrieren (und nicht wie in 
35 Fig. 2 als separate Datenbank auszubilden). 

[0062] Neben der Verwaltung der Multicast-Gruppen-Ein- 
trage fungiert das Multicast-Center MCC zusatzlich auch als 
Quelle fiir alle Multicast-Nachrichten. 
[0063] Die Fig. 3 mil 5 stellen schematisch den zeitlichen 
40 Ablauf eines logischen Verbindungsaufbaus beispieihaft 
ausgehend vom externen Netzwerk EN zum Teilnehmerge- 
rat UE4 dar. Es wird vorausgesetzt, dass sich das Teilneh- 
mergerat UE4 bereits im Funknetzwerk FN2 registriert hat, 
momentan jedoch keinen PDP Context (Paket Data Proto- 
45 koll) und keine aktive logische Ubertragungsverbindung 
zum Funknetz FN2 hat. Kommt nun ein Datenpaket PK4 fur 
das Teilnehmergerat UE4 vom externen Paketdatennetz EN, 
so wird mit dem Datenpaket PK4 eine Identifikation des 
Teilnehmergerats UE4 mitgeliefert. GGSN von Fig. 3 kennt 
50 nun entweder den SGSN an, an dem das Teilnehmergerat 
UE4 registriert ist, oder erfragt diese in der nicht eingezeich- 
neten Datenbank HLR. In diesem Ausfiihrungsbeispiel wird 
angenommen, das der GGSN weiB, dass das Teilnehmerge- 
rat UE4 am Support Node SGSN1 registriert ist. Daraufhin 
55 sendet der GGSN dem SGSN1 eine Mitteilung MPK4, dass 
ein Datenpaket PK4 fiir das Teilnehmergerat UE4 im GGSN 
angekommen ist. Der Support Node SGSN1 kennt im allge- 
meinen die sog. Routing Area, in der das Teilnehmergerat 
UE4 vermutet wird. Diese Routing- Area kann dabei meh- 
60 re re Radio Network Controller umfassen. Der S upport Node 
SGSN1 sendet daraufhin eine Anfrage RQ1, RQ2, RQ3 an 
alle in Frage kommenden Radio Network Controller, hier 
RNC1, RNC2, RNC3, ob sich das Teilnehmergerat UE4 in 
den von den Radio Network Controllem verwalteten Funk- 

65 zcllcn befindet (= Paging Request). Die Radio Network 
Controller RNC1, RNC2, RNC3 senden daraufhin eine An- 
frage IF1, IF2, IF3 in alle von ihnen verwaltete Funkzellen 
(= Paging). Das Teilnehmergerat UE4 meldet sich daraufhin 
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beim entsprechenden Radio Network Controller RNC1. Der 
Radio Network Controller RNC1 tcilt dann seiner iiberge- 
ordneten KontroUeinheit SGSN1 mil, dass das Teilnehmer- 
gerat LTR4 sich in seinem Bereich befindet. Dies ist in der 
Fig. 4 durch das Antwortsignal RE1 angedeuteL Die uber- 5 
mittelten Signale sind dabei in den Fig. 3 mil 5 jeweils durch 
dicker ausgezogene Pfeile veranschaulichL Auf dieses Ant- 
wortsignal RE1 hin, baut nun der SGSN1 togische Ubertra- 
gungsverbindungen zum GGSN (core network bearer) und 
RNC1 (Iu-Baercr) auf, die nur Daten fur das Teil rich merge- 10 
rat UE4 transportieren. Die logische Ubertragungsverbin- 
dung wird mil einem sog. PDP Context beschrieben, der alle 
notwendigen Daten der Verbindung zwischen dem Teilneh- 
mergerai und dem GGSN beinhaltet. Jeder logischen Uber- 
tragungsverbindung zwischen dem jeweiligen SGSN und 15 
GGSN ist dabei genau eine logische Ubertragungsverbin- 
dung zwischen SGSN und RNC zugewiesen, welcher wie- 
dcrum genau cine logische Ubertragungs verbindung zwi- 
schen RNC und dem Teilnehmergerai zugeordnet ist. Im 
SGSN und RNC bestehen somit feste Abbildungen der logi- 20 
schen Ubertragungsverbindungen, wodurch z. B. SGSN 
weiB. iiber welche logische Ubertragungs verbindung (und 
somit auch an welchen RNC) er eine Nachricht an das je- 
weilige Teilnehmergerai weiterleiten muss, wenn er die 
Nachrichl iiber eine beslii unite logische Ubertragungs ver- 25 
bindung von einem GGSN bekommt. In der Fig. 5 ist der 
komplette Ubertragungspfad vom GGSN zum SGSN1, wei- 
ter zum RNC1. der Basisstation BS12 und schlieBlich zum 
End-Teilnehmergerat UE4 durch einen dicker ausgezogenen 
PfeilUPll angedeutet. 30 
[0064] Fig. 6 zeigt die t)bertragungs verbindungen mehre- 
rer Teilnehmergerate in einem Funkkommunikationssystem 
FN1 emsprechend Fig. 1. Jedes Teilnehmergerai hat fur jede 
ihm zugeordnete Ubertragungs verbindung einen FTP Con- 
text. Selbst wenn die Nachrichten. die aus dem extemen 35 
Netzwerk EN an die Teilnehmergerai UE1. UE2 und UE4, 
UE5 gesendet werden sollen. exakt gleich sind, ist es erfor- 
derlich, die Nachrichten an jeden Nutzer extra separat zu 
schicken, auch wenn die physikalischen Verbindungen die 
gleichen sind. Dies ist in der Praxis zu aufwendig und belegt 40 
zu viele Ressourccn. Denn zwischen alien Netzwerkkompo- 
nenten wird jeweils eine feste Abbildung von Nutzeridenti- 
fikationen auf logische Verbindungen durchgefuhrt, d. h. fiir 
jeden einzelnen Teilnehmer wird eigens eine Verbindung 
aufgebaut. Fur die 4 Teilnehmergerate UE1. UE2. UE4, 45 
UE5 der MULT1CASTGRUPPE a werden somit im Ausfuh- 
rungsbeispiel von Fig. 6 insgesamt 4 komplette Obertra- 
gungspfade belegu die vom extemen Netzwerk EN Uber den 
GGSN, SGSN1 sowie den zugeordneten Radio Network 
Controllern RNC1, RNC2, RNC3 bis zu den Endteilneh- 50 
mergeraten durchgehend aufgebaut werden. 
100651 Fig. 7 veranschaulicht, wie Multicast Nachrichten 
vom Multicast-Sender MCC zu den Teilnehmergeraten 
UE1 , UE2, UE4, UE5 gesendet wiirden, wenn man das Kon- 
zept nach Fig. 6 der festen Zuweisung von logischen Kana- 
len zu Teilnehmergeraten hier ebenfalls anwenden wQrde. 
Obwohl Multicasi-Nachrichten, die von Multicast- Sender 
MCC gesendet werden, fur alle zu benachrichtigenden Teil- 
nehmergerate gleich sind, mussten sie dennoch fur jeden 
Nutzer einzeln zwischen Multicast- Sender MCC und 
SGSN1, SGSN1 und RNC1/RNC2/RNC3. und RNCs und 
den Endteilnehmergeraten UE1, UE2, UE4, UE5 gesendet 
werden. Dies bedeutet allgemein ausgedriickt, dass so viele 
Einzelverbindungspfade aufgebaut werden mUssten, wie 
Endtcilnchmcrgcratc durch die Multicast Nachricht zu be- 65 
nachrichugen waren. Dies ware zu aufwendig und nicht aus- 
reichend effizienL 

[0066] Um eine effizientere Verteilung von Gruppen nach- 



richten im Funkkommunikaiionsnetz FN2 von Fig. 2 zu er- 
moglichcn, wird nach einer ersten Variante des erfindungs- 
gemaBen Verfahrens zweckmaBigerweise folgendermaBen 
entsprechend den Fig. 8 mit 10 vorgegangen: 
Das Multicast Center MCC sendet eine Multicast Nachricht 
GN1 fur die Multicastgruppe A an alle SGSNs (der Einfach- 
heit halber wird im weiteren nur SGSN1 betrachtet; entspre- 
chendes gilt fur die iibrigen SGSN's) 

- SGSN1 hat nun erfindungsgemaB eine neue Funktio- 
nalitat und erkennt an Hand der mitgesendeten Multi- 
cast Gruppen Identitat, daB es sich bei der Nachricht 
um eine Multicast Nachricht handelt. 

- ErfindungsgemaB hai der SGSN1 die Multicast 
Gruppenzugehorigkeiten aller bei ihm registrierten 
Nutzer gespeichert, oder die Multicast Gruppenzuge- 
hGrigkeiten werden in der HUR Datenbank gespeichert 
und nun von SGSN dort crfragL (sichc EM). 

- Es wird angenommen, daB Nutzer UE1, UE2 und 
UE4, UE5 zu der Multicast-Omppe A gehoren. Weiter- 
hin wird angenommen, daB diese Nutzer keine aktive 
Verbindung habe. 

- SGSN1 kennt die Routing Areas in denen sich die 
Nutzer aufhalten konnten. Eine Routing Area kann 
iuehrcrc RNCs uinfassen. 

- SGSN1 sendet nun entweder 1 Anfrage AF pro Nut- 
zer (hier also 4) an alle in Frage kommenden RNCs, ob 
der Nutzer sich in einer von diesen verwalteten RNCs 
befindeL Die Anfrage AF ist in der Fig. 8 durch dicker 
eingezeichnete Pfeile angedeuteL Wenn die Routing 
Areas gleich sind, kann erfindungsgemaB auch eine 
Anfrage mit einer Liste von Nutzem an die RNCs ge- 
sendet werden. 

Die RNCs fragen wiedenim in den von ihnen ver- 
walteten Funkzellen an, ob sich einer der zu benach- 
richdgenden Teilnehmergerate der Multicast-Gruppe A 
dort befindet. (Gemeinsame Anfrage fur mehrere Nut- 
zer ist mdglich). 

- Die Nutzer rnelden sich bei den entsprechenden 
RNCs, welche wiederum die bei ihnen lokalisierten 
Nutzer zum SGSN1 melden, was in Fig. 9 durch dick 
eingezeichnete Pfeile RM angedeutet ist. 

- SGSN1 weiB nun, daB sich am RNC1 Nutzer UE4 
und UE5. am RNC2 Nutzer UE1 und an RNC3 Nutzer 
UE2 befindet. 

- ErfindungsgemaB wird nun zu jedem RNC, bei dem 
sich ein Nutzer dieser Multicast Gruppe befindet, ge- 
nau eine Ubertragungs verbindung aufgebaut. 

- Zu jedem Nutzer wind zwischen SGSN und Nutzer 
erfindungsgemaB ein Multicast Context aufgebaut, der, 
wie der PDP Context, die Verbindung beschreibt. 

[0067] Der Unterschied zum PDP Context liegt dabei 
darin, daB ein Multicast Context nicht fest einer Verbindung 
55 zugeordnet wird, sondern mehrere Multicast Contexte sich 
eine bzw. Teile der logischen Ubertragungs verbindung ge- 
meinsam nutzen. Ein Multicast Context ist jedoch ebenfalls 
nur genau einem Nutzer zugewiesen. 

60 - Jeder SGSN wird daftir erweitert, daB er einer Uber- 
tragungs verbindung mehrere MC Contexte zuordnen 
kann. Dafur muB der SGSN auch die Liste der Nutzer 
oder Multicast Contexte speichern, die diesem Iu-Bea- 
rer zugeordnet sind. 

- Jcdcr RNC wird ebenfalls crweiten, um cs zu cr- 
moglichen, die Daten nach dem RNC tiber einem Nut- 
zer zugeordnete Ubertragungsverbindungen weiterzu- 
leiten, d. h. also die Nachricht vervielfaltigen und an 
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jeden Nuizer einzeln zu schicken. Daflir wird dem je- 
weiligen RNC beim Vcrbindungsaufbau dcs Iu-Bcarers 
cine Liste der Idenutaten der Nutzer oder Multicast 
C'ontexre mitgeliefert, die dem Tu-Bearer zugeordnet 
sind. Diese Lisle wird im RNC gespeichert. 
- jeder RNC baut fur jeden Nutzer, der sich in von ihm 
verwalteten Zellen befindeu eine Ubertragungsverbin- 
dung auf. 

[0068] Es bcsteht damil eine feste Abbildung einer Multi- 
casi Gruppc auf mehrere Iu-Bearer, jedoch maximal 1 (-ein 
cinzigcr) Iu-Bcarer pro RNC]. AuBerdem besteht eine feste 
Abbildung eincs Iu-Bearers auf mehrere Radio Bearer. 
1 0069 1 Kig. 1 ] veranschaulicht noch einmal den detaillier- 
len Ablauf eines solchen Verbindungsaufbaus beispielhaft 
fur das Teilnehmergerat UE4. Es wird davon ausgegangen, 
dass sich das Teilnehmergerat UE4 zunachst im Idle-Mode 
befindct. d. h. /.war cingcschaltct ist, abcr kcinc aktivc Vcr- 
bindung /.um Funknetz FN2 aufweist. Kommt nun vorn 
Multicast -Center MCC eine Multicast Nachricht MC-Mes- 
sage. so wird in der dem Support Node SGSN1 zugeordne- 
ten Speichcrvorrichtung die Mullicast-Gruppe identifiziert, 
an die die Multicast Nachricht gerichtet ist. Damit ist dem 
SGSNI bekannt, wclche Mitglieder dieser Multicast- 
Gruppe die Muliicasi Nachricht erhalten sollen. Der SGSNI 
iniiiicn daraufhin ein Paging fur die jeweilig zu benachrich- 
tigenden Tcilnchmcrgcraie dieser Gruppe. Dazu wird an alle 
an den SGN1 angckoppelten RNCs ein Anfragesignal ge- 
sendet, ob sich in ihrcn FunkzelLenbereichen die Teilneh- 
mergerat UH1, UK2, UE4, UE5 aufhalten. Die Radio Net- 
work Control I er sen den diese Paging-Signale uber ihre zu- 
gehorigen Basissiaiioncn in ihre zu versorgenden Funkzel- 
lenbereiche aus. Bcfindet sich eines derzu benachrichtigen- 
den Teilnehmergerate im Versorgungsbereich dieser Radio 
Network Controller, so schalten diese Teilnehmergerate 
vom Idle-Mode auf dem Connected-Mode um, d. h. es wird 
eine aku vc Verbindung RRC-Connection Meldung (Radio 
Resource Conirol) zuriick an den jeweiligen Radio Network 
Controller geschickt. Derjenige Radio Network Controller - 
hier RNC1 der von seiner jeweiligen Basisstation gemel- 
del be kommt, dass sich in deren Funkzelle ein zu benach- 
richtigendes Teilnehmergerat aufhalt, macht dies auch der 
ubergeordneten Konirolleinheit - hier SGSN1 - bekannt. 
Diese fordert dann entsprechend dem Ablaufpunkt 6 von 
Fig. 11 vom jeweiligen Teilnehmergerat wie z. B. UE4 den 
Multicasi-Conicxt an, um eine Wegbeschreibung zum End- 
teilnehmergerat entsprechend Punkt 7 zuriickzuerhalten. In 
der unteren Bildhalfte von Fig. 11 ist unterhalb der gestri- 
chelten Linie der Zustand dargestellt, ab oder bei dem sich 
die Teilnehmergerate UE4 und UE5 bereits im Connected- 
Mode befinden. Dies entspricht dem Endzusiand nach der 
Signalisierung des Ablaufpunktes 7. "Aktivate Multicast- 
Context-Request". Da nun die ubergeordnete Konirollein- 
heit SGSN1 weiB, welche Radio Network Controller zustan- 
dig sind fur die zu benachrichtigenden Teilnehmergerate, 
und ein entsprechender Multicast-Context zum Verbin- 
dungsaufbau zum jeweiligen Teilnehmergerat zur Verfii- 
gung stent, wird nun vom Suppord Node SGSNI ein Verbin- 
dungsaufbau zu den zu benachrichtigenden Teilnehmergera- 
ten - hier UE4 - initiiert. Dazu wird entsprechend Ablauf- 
punkt 8 ein Iu-Baerer zwischen dem RNC1 und dem SGSNI 
aufgebaut. Zusatzlich wird die Information mitgegeben, 
dass der Iu-Baerer fur den Teilnehmer UE4 und UE5 be- 
steht. Daraufhin wird zwischen dem RNC1 und den Endteil- 
nehmergeraten UE4 und UE5 jewcils cin Radio-Bacrcr ent- 
sprechend dem Ablaufpunkt 9 aufgebaut und dies entspre- 
chend dem Ablaufpunkt 10 dem Radio Network Controller 
RNC1 bestatigt. Damit konnten Radio-Baerer zu alien End- 
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teilnehmergeraien - hier UE4, UE5 die am Radio Net- 
work Controller RNC 1 angekoppelt sind, aufgebaut werden. 
Gleichzeiug wird die Abbildung von einem einzelnen Iu- 
Baerer zwischen dem Radio Network Controller RNCl und 
5 der ubergeordneten Konirolleinheit SGSN1 auf mehrere Ra- 
dio-Baerer zwischen Radio Network Controller RNC I und 
den Endteilnehmergeraten UE4, UE5 im Radio Network 
Controller RNC1 gespeichert. Dieser bestatigt den Aufbau 
des Iu-Baerers nach Ablaufpunkt 11. Daraufhin sendet der 
10 Support Node SGSN1 cin Bestatigungssignal Aktivate Mul- 
ticast Context Exepl nach Ablaufpunkt 12 an den jeweiligen 
Endteilnehmer IJE4 bzw. IJE5. SchlieBlich wird uber den 
aufgebauten Ubertragungspfad die Multicast Nachricht vom 
SGSN1 an die Endteilnehmergerate UE4, UE5 ubertragen. 
15 [0070] Bei dem Ubertragungskonzept entsprechend den 
Fig. 10 und 11 wird also zusammenfassend betrachtet zu- 
nachst die Multicast Nachricht fur die Mullicast-Gruppe A 
an den Support Node SGSN1 ubertragen. Der Support Node 
SGSN1 kennt aufgrund seiner SpeicherzugrifFsmoglichkeit 

20 diejenigen Radio Network Controller und die logischen 
Ubertragungsverbindung (Iu-Bearer), die fur Nachrichten 
der Multicast-Gruppe A aufgebaut wurden, und sendet die 
Multicast Nachricht nur einmal zu jedem der Radio Net- 
work Controller, mit denen ein Nutzer dieser Multicast- 

25 Gruppe verbunden ist. Der jeweilige Radio Network Con- 
troller kennt die Nutzer der Muuicast-Gruppe A und die lo- 
gischen Ubertragungsverbindungen zu den Nutzem (Radio 
Baerer), die mit dem Iu-Baerer also der am RNC ankom- 
menden Verbindung verkniipft sind. Der jeweilige Radio 

30 Network Controller sendet nun die Multicast Nachricht der 
Multicast-Gruppe A uber die aufgebauten Verbindungen 
(Radio Baerer) fur jeden Nutzer einmal. Obwohl also hier 
im Ausfuhrungsbeispiel von Fig. 10 vom Radio Network 
Controller RNC 1 mehrere Teilnehmergerate UE4, UE5 ver- 

35 sorgt werden, wird lediglich ein einzelner Ubertragungspfad 
zwischen dem Radio Network Controller RNCl und dem 
ubergeordneten Support Node SGSN1 aufgebaut und be- 
nutzt. Dies ermoglicht eine effizienie Verteilung der Multi- 
cast Nachricht GN1. 

40 10071] Fig. 12 zeigt eine weitere Variante zur erfindungs- 
gemaBen Verteilung von Multicast Nachrichten zwischen 
dem Multicast-Sender MCC und den zu benachrichtigenden 
Endteilnehmergeraten einer bestimmten Multicast-Gruppe 
wie z. B. A. Vom Support Node SGSN1 wurde wie in Fig. 

45 10 zum RNCl ebenfaUs eine logische Ubertragungsverbin- 
dung (Iu-Baerer) pro Nutzer aufgebaut. Des Multicast-Cen- 
ter MCC sendet dabei die Muldcast Nachricht GN1 vor- 
zugsweise nur einmal. Der Support Node SGSN1 kennt er- 
tindungsgemaB die Teilnehmergerate dieser Multicast- 

S0 Gruppe A aufgrund seiner Zugriffsmoglichkeit in die Spei- 
chervorrichtung SP1 von Fig. 2 und damit die zugehdrigen 
logischen Ubertragungsverbindungen zu den Radio Net- 
work Controllern. Der Support Node SGSN1 vervielfaltigt 
die eingehende Muldcast Nachricht GN1 und sendet diese 

55 Nachricht jeweils einmal pro Teilnehmergerat an die ent- 
sprechenden Radio Network Controller RNCl, RNC2, 
RNC3, Da am Radio Network Controller RNCl hier im 
Ausfuhrungsbeispiel 2, d. h. allgemein ausgedruckt mehrere 
Teilnehmer hangen, werden entsprechen viele logische 

60 Ubertragungsverbindungen zu Ubermittlung der Grupppen- 
nachricht GN1 bereitgestellt zwischen den Support Node 
SGSN1 und dem Radio Network Controller RNCl. Im Ein- 
zelnen heiBt das, dass ein Ubertragungspfad UP11* zwi- 
schen den Support Node SGSN1 und dem Radio Network 

65 Controller RNCl fur das Teilnehmergerat UE4.sowic cin 
weilerer, zweiter Ubertragungspfad UP1 1 ** fur das Teilneh- 
mergerat UE5 abgestellt wird. Vorteilhaft bei dieser Uber- 
tragungsvariante ist insbesondere: Es ist keine neue Funk- 
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lionalitat ira jewciligen Radio Network Controller erf order- 
lie h. Die iibcrgeordente Funknetzwerk-Kontrollcinhcit 
SGSN1 kann weiierhin ahnlich dem PDP Context eine \fer- 
hinriung pro Nutzer aufhauen. Fur die ubergeordnete Funk- 
netzwerk-Kontrolleinheit SGSN1 und dem jeweiligen Ra- 5 
dio Network Controller ist es nicht erforderlich, eine Liste 
der Multicast-Context bzw. Teilnehmergerate der jeweilig 
zu benachrichtigenden Multicast-Gruppe zu fuhren, die zu 
einer logischen Ubertragungsverbindung gehoren. Auf diese 
Weise ist eine Umanderung der Signalisierung zwischen den 10 
Netzwerkkomponenten best ehen der Mobil fun knetze weit- 
gehend vermieden. Ledigiich die Einfuhrung eines Multi- 
cast-Senders sowie einer zentral gefuhrten Datenbank fur 
die Multicast-Gruppen ist zur Durchfuhrung des erfindungs- 
gemaBen Verfahrens zweckmaBig. 15 
[0072] Fig. 13 zeigt diesen Verbindungsaufbau passend zu 
Fig. 12 nochmals ini Detail. Anderungen gegenOber dem 
Vcrfahrcn von Fig. 1 1 sind jewcils grau untcrlcgt gczcich- 
net. 

10073) Fig. 14 zeigt schlieBlich einen Registrierungspro- 20 
zess beispiethaft fur Teilnehmergerat UE4. Schaltet das 
Teilnehmergerat UE4 sein Mobilfunkgerat an, wird zu- 
nachst eine Radio Resource Controll Verbindung zum Radio 
Network Controller RNC1 aufgebauL AnschlieBend authen- 
Ufiziert sich das Teilnehmergerai UE4 am Support Node 25 
SGSN1 . Dabei wird bei der Authentifizierung die Multicast- 
Gruppenzugehorigkeit des Teilnehmergerats UE4 zum Sup- 
port Node SGSN1 ubertragen. Der Support Node SGSN1 
speichert diese Informaiionen in einer internen oder exter- 
nen Datenbank. Altemativ konncn die Informationen auch 30 
an eine exteme Datenbank wie z. B. einem erweiterten 
Home Location Register HLR weitergeleitet werden. Dafur 
wird eine Identification des Teilnehmergerats UE4 sowie 
Idenufikauonen der Multicast-Gruppen dieses Teilnehmer- 
gerats an eine solche Datenbank gesendet. 
[0074] Zusammenfassend betrachtet sind somit folgende 
Schritte zum effizienten Verteilen von Multicast Nachrich- 
ten in einem Funkkommunikationssystem vorteilhafu 

1. Einfuhrung eines logischen Netzwerkelementes 40 
"Multicast Center": 

Das Multicast Center hat die Aufgabe, die Multicast 
Gruppen zu verwalten. die Informationen fur die Mul- 
ticast Gruppen bereitzustellen und sie an alle SGSNs 
im UMTS Netzwerk zu senden. Dazu speichert es 
zweckmafiigerweise auch eine Identitat einer Multicast 
Gruppe, die im gesamten Netzwerk eindeutig ist. 

2. Erweiterung der SGSN Funktionalitat um die Fa- 
higkeit zu erkennen. daB es sich bei einer empfangenen 
Nachricht um eine Multicast Nachricht handelL 

3. Erweiterung des SGSN um die Fahigkeit, Multicast 
Gruppenzugehorigkeiten der an dem SGSN regis trier- 
ten Nutzer zu speichem. 

4. Altemativ zu 3. kann die Gruppenzugehorigkeitsin- 
formation auch in einer extemen Datenbank (z.B. 
HLR) gespeichert werden. Dazu wird die HLR Funk- 
tionalitat zweckmafiigerweise erweitcrt AuBerdem 
wird der SGSN zweckmaBigerweise die zusatzliche 
Fahigkeit gegeben. die Gruppenzugehorigkeiten bei 
der extemen Datenbank zu erfragen. 

5. Erweiterung der SGSN Funktionalitat durch die Fa- 
higkeit Daten zu speichem. die eine fur einen nutzer- 
spezifische Verbindung zum SGSN beschreiben. Diese 
Daten werden im weiteren Mulucast Contexte genannL 

6. ErfindungsgcmaB gehoren zum Multicast Context 
mindestens eine Identifikation des Nutzers und eine 
Identifikation der Multicast Gruppe. 

7. Erweiterung der SGSN Funktionalitat durch die Fa- 
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higkeit, eine logische Ubertragungsverbindung fur 
mehrere Multicast Contexte zwischen SGSN und RNC 
aufzubauen, die zur selben Multicast Gruppe gehoren 
und die Liste der Multicast Contexte dieser Uhenra- 
gungsverbindung zu speichem und zu aktualisieren 
(wenn z. B. ein Nutzer den RNC wechselt). 

8. Erweiterung der RNC Funktionalitat durch die Fa- 
higkeit, eine Liste der Multicast Contexte bzw. Nutzer 
zu speichem und zu aktualisieren, die zu einer logi- 
schen Verbindung zwischen RNC und SGSN gehoren. 

9. Erweiterung der RNC Funktionalitat durch die Fa- 
higkeit eine logische fJbertragungsverbindung zwi- 
schen RNC und SGSN (Iii-Bearer) auf mehrere logi- 
sche Ubertragungsverbindungen zwischen RNC und 
Nutzer bzw. UE (Radio Bearer) abzubilden. 

10. Hinzufugen der Multicast-Gruppenzugehorigkeit 
eines Nutzers in die Registrierungsnachricht, damit 
dicsc im SGSN gespeichert werden kann, bzw. vom 
SGSN an eine exteme Datenbank (z. B.) HLR weiter- 
geleitet werden kann. wo sie dann gespeichert wird. 

[0075] Im Weiteren wird auf die Einfuhrung der effizien- 
ten Verteilung von Multicast Nachricht insbesondere im 
Hinblick auf UNTS eingegangen: 

1 . Eintrag der MC-Gruppenzugehorigkeit in eine Datenbank 

[0076] Das im Internet verwendete Protokoll IGMP zur 
Erfassung der Teilnehmer von Multicast-Gruppen ist fiir 
UMTS nicht gut geeignet. Durch das "Nachfragen" (Query, 
Report) nach der Multicast-Gruppenzugehorigkeit bei alien 
Hosts, somit also auch bei solchen, die keine Teilnehmer der 
entsprechenden Multicast-Gruppe enthalten, kommt es zu 
zusatzlicher Ubertragungs-Komplexitat und sornit erhohtem 
Bandbreitebedarf. 

[0077] Im Rahmen dieser Erfindung soli der Eintrag der 
Zugehorigkeit von Teilnehmem zu Multicast-Gruppen in 
eine zentrale Datenbank vorgenommen werden (Fig. 19). 
Im UMTS-Corenetwork kann dafur moglicherweise das 
HLR, HSS (home subscriber server), VLR, der SGSN oder 
der GGSN verwendet werden. 

[0078] Teilnehmer, die zu einer bestimmten Multicast- 
Gruppe beitreten oder diese verlassen wollen, senden eine 
Nachricht, eventuell iiber verschiedene Netzwerkknoten. 
45 entweder direkl an die Datenbank oder an einen Netzwerk- 
knoten. der wiederum den Eintrag in die Datenbank vor- 
nimmL Der Netzwerkknoten, der die Eintragung in die Da- 
tenbank vomehmen soli, kann beispiels weise der SGSN 
sein. 

50 [0079] Kommt es nun zur Ubertragung einer Multicast- 
Nachrichl, ertblgt zuerst eine Anfrage an diese Datenbank, 
ob und welche Teilnehmer der entsprechenden Multicast- 
Gruppe angehoren. 

[0080] Der Vorteil dieses Verfahrens ist, dass die Zugeho- 
55 rigkeit von Teilnehmem zu Multicast-Gruppen aus einer 
zentralen Datenbank erfragt werden kann. 
[0081] Zusatzliche Ubertragungskomplexitat und der so 
entstehende zusatzliche Bandbreitebedarf wie fur das IGMP, 
wie es beispielsweise im Internet praktiziert wird. wird so 
60 vermieden. 

[0082] Der Eintrag in die Datenbank kann ggf. auch ge- 
trennt vom UMTS -Netzwerk beispielsweise durch den 
Netzbetreiber durchgefiihrt werden. 

65 Ausflihrungsbcispicl 

[0083] Fiir das Ausfuhrungsbeispiel wird angenommen, 
dass sich Teilnehmer X bei einer Multicast-Gruppe anmel- 
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den will. Mil Hilfe einer entsprechenden Applikation gene- 
ricrt er eine Registrierungs-Anforderung (Subscriber-Nach- 
richl), welche mind, seine Identitat (EMSI, IP-Adresse o. a.) 
und die MC-Adresse der entsprechende Multicast-Gruppe 
enthalt. Diese Subscriber-Nachricht sendet er nun iiber den 5 
RNC zum SGSN (Serving GPRS Support Node). 
[0084] Der SGSN erkennt, dass es sich um eine Registrie- 
rungs-Anforderung handelt und veranlasst einen Eintrag in 
die zentrale Datenbank. 

[0085] Die Adrcssen der Teilnehmer der entsprechenden 10 
MC-Gruppen konnen fur den Transport der MC-Nachrich- 
icn zu den Teilnehmern aus der Datenbank abgefragt wer- 
den. Don erfolgt ein Mapping von Teilnehmer auf Multi- 
casi-Gruppe bzw. Mulitcast-Gruppe auf Teilnehmer. Mit 
Hilfe dicser Information aus der Datenbank in Kombination 15 
mil der Location Information aus dem SGSN, welcher RNC 
den MC- Teilnehmer bedient, konnen nun die MC-Nachrich- 
icn zu den entsprechenden SRNC und daraufhin zu den MC- 
Tcilnehrncrn ubertragen werden. 

20 

2. MC-Context activation 

[0086] Naeh dem Einschalten eines UE wird als erstes 
eine Registrierungs- und Authentifizierungsprozedureinge- 
leiiei. Dafiir geht das UE zuerst in den Connected Mode 25 
iiber. Uber den Aufbau einer RRC-Connection zum RNC 
und einer Signalisierung zum SGSN macht sich das UE 
bcim SGSN bekannl. 

[0087] Dem SGSN isi nun unter anderem die Identitat des 
UE und des RNC bekannt, der das entsprechende UE ver- 30 
sorgt. 

[0088] Kommi es zu keinen weiteren Aktionen des UE 
(Gespraehsaufbau. Dai en ubertragung etc.) so fallt es in den 
Idle-Mode. Siimiliche Vcrbindungen werden abgebaut und 
der SGSN hat Icdiglich Information iiber die Identitat des 35 
UE und die Routing -Area in der es sich befindet. 
[0089] Das hier vorgcsteilte Verfahren, bezeichnet als 
"Multicast-Context activation", beschreibt den Prozessab- 
lauf, wie sich ein UE mit seinen MC-Gruppenzugehorigkei- 
ten beim SGSN bekannl macht. 40 
[0090] Nach dieser Prozedur sind dem SGSN wie bisher 
die Identitat und die Location Information, zusatzlich nun 
aber auch die MC-Gruppenzugehorigkeiten des UE be- 
kannl. 

[0091] Eine Moglichkcit zur Aktivierung eines MC-Con- 45 
textes isu dass ein UE beim Einschalten und der darauf fol- 
genden Registrierungs- und Authentifizierungsprozedur je- 
des Mai standard rnaSig (default) seine MC-Gruppen zuge- 
horigkeit zum SGSN mil iiber tragt (Fig. 20). Diese Infor- 
mationen werden im SGSN gespeichert und bilden den MC- 50 
Context. 

[0092] Fallt das UE daraufhin in den Idle-Mode (im Falle 
keiner weiteren Aktionen des UE), so muss der SGSN neben 
den Informaiionen iiber die Identitat und die Routing-Area 
des UE nun auch die MC-Gruppenzugehorigkeits-Informa- 55 
tionen speichern. 

[0093] Denkbar ist auch der Fall, dass die MC-Gruppen- 
zugehorigkeits-In formation nach dem Einschalten eines UE 
und der darauf folgenden Registrierungs- und Authentifizie- 
rungsprozedur standardmafiig (default) vom SGSN aus ei- 60 
ner Datenbank (siehe Eintrag der MC-Gruppenzugehorig- 
keit in eine Datenbank) abgefragt wird (Fig. 21). Diese In- 
formationen werden im SGSN gespeichert und bilden den 
MC-Context. 

[0094] Fallt das UE daraufhin in den Idle-Mode (im Falle 65 
keiner weiteren Aktionen des UE), so speichert der SGSN 
neben den In formation en iiber die Identitat und die Routing- 
Area des UE nun auch die MC-Gruppenzugehorigkeits-In- 



formationen. 

[0095] Eine weitere Moglichkeit ist, dass die MC-Grup- 
penzugehorigkeits-Information beim Eintreffen einer MC- 
Message bzw. eines MC-Message-Request vom SGSN aus 
einer Datenbank (siehe Eintrag der MC-Gruppenzugehorig- 
keit in eine Datenbank) abgefragt wird (Fig. 22). Diese In- 
formationen werden im SGSN gespeichert und bilden den 
MC-Context. Vorteil dieser Variante ist, dass die MC-Grup- 
penzugehorigkeus-Information nicht standig im SGSN ge- 
speichert werden muss, sondem nur dann, wenn MC-Nach- 
richten eintreffen bzw. ubertragen werden. 
[0096] Darnit die MC-Gmppenzugehorigkeits-Informa- 
tion aber nicht bei jeder einzelnen MC-Nachricht einer be- 
stimmten Gruppe oder sogar bei jedem einzelnen IF-Packet 
einer MC-Nachricht neu abgefragt werden muss, kann ein 
Timer initialisiert werden. 

[0097] Kommt es nun zu einer erneuten Ubertragung einer 
MC-Nachricht, bevor der Timer abgclaufcn ist, so muS die 
MC-Gmppenzugehdrigkeits-In formation nicht erneut abge- 
fragt werden, da die Informationen wahrend der Laufzeit 
des Timers gespeichert wird. 

[0098] Grundsatzlich kommt es zu einem Update der MC- 
Gruppenzugehorigkeits-Information im SGSN, wenn sich 
neue Mitglieder zu einer MC-Gruppe anmelden bzw. diese 
verlassen (siehe dazu Abschnitt 1. Eintrag der MC-Grup- 
penzugehorigkeit in eine Datenbank). 

3. Aufbau der Verbindungswege und Ubertragung der MC- 
Nachrichten 



I. Ausfuhrungsbeispiel 

[0099] Fiir dieses Beispiel wird angenommen, dass eine 
MC-Nachricht im EP-MC-Center (MCC) generiert wurde 
und nun zu den Teilnehmern dieser MC-Gruppe gesendet 
werden soil. Diese MC-Nachricht ist mit der MC-Adresse 
der entsprechenden MC-Gruppe adressiert. Das EP-Multi- 
cast-Center hat die Funktionalitat eines IP-MC-Routers. 
[0100] Die MC-Nachricht wird nun zu alien SGSNs ge- 
sendet (1. in Fig. 23). Aufgrund der Aktivierung des MC- 
Kontextes (siehe Abschnitt 2. MC-Context activation) sind 
dem SGSN die UEs und ihre MC-Gruppenzugehorigkeiten 
bekannt. Das SGSN kennt die UES, die die MC-Nachricht 
erhalten sollen und deren Routing Areas (RA), in denen sich 
die UEs befinden. 

[0101] Befindet sich ein UE, das Mitglied der entspre- 
chenden MC-Gruppe ist, im Idle-Mode, so wird nun vom 
SGSN ein MC-Message-Request an alle RNCs in der ihm 
bekannten Routing Area gesendet (2. in Fig. 23). Dieser 
MC-Msg.-Request beinhaltet die Identitat der UEs (z. B. 
IMS I. IP-Adresse o. a.) und die MC-Adresse der entspre- 
chenden MC-Gruppe. 

[0102] Die RNCs fuhren daraufhin ein Paging der UEs 
durch, die im MC-Msg.-Request benannt sind (3. in Fig. 

23). 

[0103] Diese UEs bauen nun eine RRC-Connection und 
Radio Bearer (RB) zum RNC auf und befinden sich darauf- 
hin im Connected Mode (4. in Fig. 23). 
[0104] Befindet sich ein UE, das Mitglied der entspre- 
chenden MC-Gruppe ist, bereits im Connected-Mode, so 
wird ein MC-Msg.-Request von SGSN iiber die RNCs zu 
den entsprechenden UEs, welche Mitglieder der MC- 
Gruppe sind, gesendet (5. in Fig. 23). Dieser MC-Msg.-Re- 
quest beinhaltet die Identitat der UEs (z. B. IMSL IP- 
Adrcssc o. a.) und die MC-Adrcssc der entsprechenden MC- 
Gruppe. 

[0105] Da sich die UEs bereits im Connected Mode befin- 
den (RRC Connection besteht), mussen nun (soweit noch 
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nichi vorhanden) Radio Bearer (RB) zura RNC aufgebaui 
wcrdcn (6. in Fig. 23). 

[0106] Nachdem sich nun alle UEs der MC-Gruppe im 
Connected Mode hefinden und sowohl eine "RRC-Cnnnec- 
lion als auch Radio Bearer aufgebaui sind. wird nun von je- 5 
dem RNC. dcr Mitglieder der MC-Gruppe versorgt, zum 
SGSN cin MC-Bearer pro RNC aufgebaui (7. in Fig. 23). 
Hin MC-Msg .-Confirm., der vom RNC uber diese MC-Bea- 
rcr gcscndci wird, gibi nun dem SGSN die Bereiischaft der 
Ulis kund, MC-Nachrichten cmpfangen zu kdnnen. Der 10 
SGSN hai nun die Informationen, wo sich die UEs der MC- 
Gruppe befinden und kann nun die MC-Nachricht iiber die 
/.uvor aufgebauten MC-Bearer zu dem entsprecbenden 
RNCs senden (8. in Fig. 23). 

1 0107 1 Mil der Mapping-Informauon (UE/MC-Gruppe) 15 
aus dem MC-Msg.-Request kann die MC-Nachricht nun zu 
den Ul is dcr MC-Gruppe ubertragen werden (9. in Fig. 23). 
10108] Hin SGSN, dcr cine MC-Nachricht fur cine bc- 
siitmutc MC-Gruppe bekommi aber keine Mitglieder dieser 
MC-Gruppc versorgt, bendtigt diese Nachricht nicht und 20 
kann sic verwerfen. 

1 0109| Mine wciicre Moglichkeit ist, dass der SGSN, so- 
fern cr keine Mitglieder der MC-Gruppe besitzt, eine Pnine- 
Nachrichi ( Vergl. RPM) an das EP-Multicast-Center zuriick 
scrulci. Dieser SCiSN erhalt dann solange keine MC-Nacb- 25 
richicn liir die MC-Gruppe, bis: 

dcr SGSN an das IP-MC-Center eine Join-Nachricht 
scndci. die den Eintriti eines Teilnehmers in eine MC- 
Gruppe signalisiert (event- triggered). 30 

cin /.uvor festgelegter Timer abgelaufen isL 

10110] Dciikbar isi auch der Fall, dass die MC-Nachricht, 
nachdem sie im MCC generiert wurde, nicht sofort an alle 
SGSNs gcscndci wird (VergL 1. in Fig. 23). Stattdessen 35 
kann auch /.ucrsi cin MC-Message-Request zu den SGSNs 
gesendet wcrdcn (1. in Fig. 24). 

[0111] Die wcitercn Prozeduren zum Aufbau der Verbin- 
dungen fur die Obcrtragung der MC-Nachricht vom SGSN 
zu den Ulis der MC-Gruppe-Teilnehmer bleiben dann gleich 40 
(2. bis 7. in Fig. 24). 

|0112| Nachdem dann der MC-Msg.-Req. beim SGSN 
eingegangen isi (7. in Fig. 24), wird nun ein Bearer (pro 
SGSN) vom SGSN zum MCC aufgebaut und es erfolgt ein 
MC-Msg.-Req. an das MCC (8. in Fig. 24). 45 
|0113] Ersi jclzi sendet das MCC die MC-Nachricht an 
alle SGSNs zu denen Bearer aufgebaut sind und von denen 
erdie MC-Msg.-Req. erhalien hat (9. in Fig. 24). 
[0114] Die wcileren Schritte (10. und 11. in Fig. 24) sind 
nun wiedcr idcniisch mil 8. und 9. aus Fig. 23. 50 
[0115] Eine wcitere Moglichkeit ist. dass nach dem Ein- 
ireffen des MC-Msg.-Req. beim SGSN (7. in Fig. 25) nun 
ein Bearer pro RNC vom SGSN zum MCC aufgebaut wird 
(8. in Fig. 25). Uber diese RNC-spezifischen Bearer werden 
nun die MC-Nachrichten iiber den SGSN zu den entspre- 55 
chenden RNCs weitergeleiiet (9. in Fig. 25). 
[0116] Mil der Mapping-Information (UE/MC-Gruppe) 
aus dem MC-Msg.-Request kann die MC-Nachricht nun zu 
den UEs dcr MC-Gruppe ubertragen werden (10. in Fig. 
25). „ 60 

[0117] Damit die Verbindungswege (Bearer) fur die Uber- 
tragung der MC-Nachrichten zu den einzelnen UEs einer 
MC-Gruppe nicht fur jede einzelne MC-Nachricht einer be- 
stimmien Gruppe oder sogar bei jedem einzelnen IP-Packet 
cincr MC-Nachricht ncu aufgebaut wcrdcn miisscn, kann 65 
ein Timer initialisiert werden. Die Verbindungen (Bearer) 
werden nun solange aufrecht erhalten. bis der Timer abge- 
laufen ist. Kommt es zu einer emeuten Ubertragung einer 
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MC-Nachricht, bevor der Timer abgelaufen ist, so wird die 
MC-Nachricht iiber die noch bestebenden Vferbindungswege 
ubertragen. 

[0118] Eine weitere Moglichkeit ist der Ahhau der Bearer 
durch explizite Signalisierung ausgehend vom MCC, SGSN 
oder beiden. 

II. Ausfuhningsbeispiel 

[0119] Fiir dieses Beispiel wird cmeut angenommen, dass 
eine MC-Nachricht im IP-MC-Cenier generiert wurde und 
nun zu den Teilnehmem dieser MC-Gruppe gesendet wer- 
den soil. Diese MC-Nachricht ist mil der MC-Adresse der 
entsprechenden MC-Gruppe adressiert. Das IP-Multicast- 
Cenier hat die Funkuonalitat eines IP-MC-Routers. 
[0120] Die Schritie 1. bis 6. sind jeweils ideniisch mil de- 
nen aus Verfahren I. 

[0121] Nachdem sich nun alle UEs dcr MC-Gruppc im 
Connected Mode befinden und sowohl eine RRC-Connec- 
lion als auch Radio Bearer aufgebaut sind. wird nun von je- 
dem RNC, der Mitglieder der MC-Gruppe versorgt, zum 
SGSN ein Iu-Bearer pro UE aufgebaui (7. in Fig. 26). Ein 
MC-Msg. -Con firm., der vom RNC uber diese Iu-Bearer ge- 
sendet wird, gibt nun dem SGSN die Bereiischaft der UEs 
kund, MC-Nachrichlen cmpfangen zu konnen. Der SGSN 
hai nun die Informationen, wo sich die UEs der MC-Gruppe 
befinden und kann nun die MC-Nachricht uber die zuvor 
aufgebauten Iu-Bearer zu dem entsprechenden UE senden 
(8. in Fig. 26). 

[0122] Ein SGSN, der eine MC-Nachricht fur eine be- 
stimmte MC-Gruppe bekommi, aber keine Mitglieder dieser 
MC-Gruppe versorgt, benougt diese Nachricht nicht und 
kann sie verwerfen. 

[0123] Eine weitere Moglichkeit ist, dass der SGSN, so- 
fem er keine Mitglieder der MC-Gruppe besitzt, eine Prune- 
Nachricht (VergL RPM) an das D^Muliicast-Center zuriick- 
sendet. Dieser SGSN erhalt dann solange keine MC-Nach- 
richten fur die MC-Gruppe, bis: 

- der SGSN an das IP-MC-Center eine Join-Nachricht 
sendet, die den Einlritt eines Teilnehmers in eine MC- 
Gruppe signalisiert (eveni-iriggered). 

- ein zuvor festgelegter Timer abgelaufen ist. 

[0124] Denkbar isi auch der Fall, dass die MC- Nachricht, 
nachdem sie im MCC generiert wurde, nicht sofort an alle 
SGSNs gesendet wird (Vergl. 1. in Fig. 26). Stattdessen 
kann auch zuerst ein MC-Message-Request zu den SGSNs 
gesendet werden (1. in Fig. 27). 

[0125] Die weiteren Prozeduren zum Aufbau der Verbin- 
dungen fur die Ubertragung der MC-Nachricht vom SGSN 
zu den UEs der MC-Gruppen-Teilnehmer bleiben dann 
gleich (2. bis 7. in Fig. 27). 

[0126] Nachdem der MC-Msg.-Req. beim SGSN einge- 
gangen ist (7. in Fig. 27), wird nun ein Bearer (pro SGSN) 
vom SGSN zum MCC aufgebaut und es erfolgt ein MC- 
Msg.-Req. an das MCC (8. in Fig. 27). 
[0127] Erst jetzt sendet das MCC die MC-Nachricht an 
alle SGSNs, zu denen Bearer aufgebaut sind und von denen 
er die MC-Msg.-Req. erhalten hat (9. in Fig. 27). 
[0128] Die Ubertragung der MC-Nachricht iiber die Iu- 
Bearer zu den UEs der MC-Gruppe ist nun wieder identisch 
mit der aus Fig. 26. 

[0129] Eine weitere Moglichkeit ist. dass nach dem Ein- 
ircffcn des MC-Msg.-Rcq. beim SGSN (7. in Fig. 28) nun 
ein Bearer pro UE vom SGSN zum MCC aufgebaut wird (8. 
in Fig. 28). 

[0130] tjber diese UE-spezifischen Bearer werden nun die 
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MC-Nachrichten fiber die SGSNs und die RNCs zu den ent- 
sprechenden UEs weitergeleitet (9. in Fig. 28). 
[0131] Damit die Verbindungswege (Bearer) fur die tjber- 
tragung der MC-Nachrichten zu den einzelnen URs einer 
MC-Gruppe nicht fur jede einzelne MC-Nachricht einer be- 5 
stimmten Gruppe odcr sogar bei jedem einzelnen IP-Packet 
einer MC-Nachricht neu aufgebaut werden miissen, kann 
ein Timer initialisiert werden. Die Verbindungen (Bearer) 
werden nun solange aufrecht erhalten, bis der Timer abge- 
laufen ist. Kommt es zu einer emeuten Ubertragung einer 10 
MC-Nachrichu bevor der Timer abgelaufen ist, so wird die 
MC-Nachricht uber die noch bestehenden Verbindungswege 
iibertragen. 

[0132] Eine weitere Moglichkeit ist der Abbau der Bearer 
durch explizite Signalisierung ausgehend vom MCC, SGSN 15 
Oder bei den. 

[0133] Weitere Hinweise, Definidonen, Funktionsanga- 
bcn zu den Funknctzwcrkclcmcnt.cn von UMTS finden sich 
insbesondere in folgenden Spezifikauonen: 

20 

- 3G TS 23.002 V3.3.0, Technical Specification 
Group Services and Systems Aspects, Network archi- 
tecture, Release 1999 

- 3G TR 21.905 V3.2.0, Technical Specification 
Group Services and Systems Aspects, Vocabulary for 25 
3GPP Specifications, Release 1999 

- 3G TS 23.060 V3.4.0, Technical Specification 
Group Services and Systems Aspects, General Packet 
Radio Service (GPRS), Service description, Stage 2, 
Release 1999 30 

[0134] Folgende Abkurzungen wurden in Zusammengang 
mit der Beschreibung der Erfindung insbesondere verwen- 
det: 

[0135] Grundsatzlich: Mehrzahlbildung durch Anhangen 35 
eines 's\ z. B.: ein RB, zwei RBs 
CN: Core-Network 

GGSN: Gateway GPRS Support Node 
GPRS: General Packet Radio Service 

GSM: Global System for Mobile communications 40 

HLR: Home Location Register 

HSS: Home Subscriber Server 

IGMP: Internet Group Management Protocol 

IMSI: International Mobile Subscriber Identity 

IP: Internet Protocol 45 

MC: Multicast 

MCC: Multicast-Center 

MM: Mobility Management 

MS: Mobile Station 

MSC: Mobile Switching Center 50 

MSISDN: MS International ISDN Number 

PDP: Packet Data Protocoll 

PLMN: Public Land Mobile Network 

RNC: Radio Network Controller 

RNS: Radio Network Subsystem 55 
RPM: Reverse Path Multicasting 
SGSN: Serving GPRS Support Node 
SM: Session Management 
TJE: User Equipment 

UMTS: Universal Mobile Telecommunication System 60 
UTRAN: UMTS Terrestrial Radio Access Network 
VLR: Velocity Location Register 

Paten tan sprue he 

65 

1. Verfahren zum Verieilen einer Gruppennachricht 
(GN1) an mindestens eine Gruppe (A) von Teilnehmer- 
geraten eines Funkkommunikationssy stems (FN2), 



wobei in mindestens einer Speichervorrichtung (SP1) 
die ein oder mehreren Teilnehmergerate der jeweiligen 
Gruppe (A) unter einer gemeinsamen Idendfizierungs- 
adresse (TDA) abgelegt worden sind und dort fortlau- 
fend aktualisiert werden, wobei zur Verteilung der je- 
weiligen Gruppennachricht (GN1) durch mindestens 
ein Multicast-Center (MCC) an die Mitglieder-Teilneh- 
mergerate (UE1, UE2, UE4, UES) einer ausgewahlten 
Gruppe (A) diese zu veneilende Gruppennachricht 
(GN1) lediglich Ciber einen gemeinsamen Ubertra- 
gungspfad (GP) an mindestens eine iibergeordnete 
Funknetzwerk-Kontrolleinheit (SGSN1) gesendet 
wird, mittels der Speichervorrichtung (SP1) die aktueil 
zugehorigen, zu benachrichtigenden Teilnehmergerate 
(UE1, UE2. UE4, UES) dieser ausgewahlten Gruppe 
(A) ermittelt, und diese der Ubergeordneten Funknetz- 
werk-Kontrolleinheit (SGSN1) mitgeteilt werden. und 
wobei dann von dicscr iibcrgcordnctcn Funknetzwerk- 
Kontrolleinheit (SGSN1) mindestens ein Ubertra- 
gungspfad (UP11) zur Verteilung der Gruppennach- 
richt (GN1) an die ermittelten Mitglieds-Teilnehmerge- 
rate (UE1, UE2, UE4, UES) der ausgewahlten Gruppe 
(A) unter Zuhilfenahme einer oder mehrerer unterge- 
ordneterFunknetzwerk-Kontrolleinheiten (RNC1) be- 
reitgeslellt wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dassdie Verteilung der Gruppennachricht (GN1) in 
einem UMTS (Universal Mobile Telecommunication 
System), GPRS (General Packet Radio Service), 
EDGE (enhanced data rates for GSM environments), 
und/oder OFDM (Orthogonal Frequency Division 
Multiplexing)-Funkkommunikadonssystem durchge- 
fiihrt wird. 

3. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als iibergeordnete 
Funknetzwerkkontrolleinheit (SGSN1) jeweils ein Ser- 
ving GPRS Support Node von UMTS verwendet wird. 

4. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als untergeordnete 
Funknetzwerkkontrolleinheit (RNC1) jeweils ein Ra- 
dio Network Controller von UMTS verwendet wird. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass von der jeweiligen 
untergeordneten Funknetzwerkkontrolleinheit (RNC1) 
jeweils ein Verbindungsaufbau zu derjenigen Basissta- 
tion (BS11, BS12) ihres Versorgungsbereiches iniuiert 
wird, in deren Funkzelle sich das jeweilig zu benach- 
richtigende Teilnehmergerat (UE4) aufhalt. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass fur die Ubermitt- 
lung der Gruppennachricht (GN1) von der iibergeord- 
neten Funknetzwerkkontrolleinheit (SGSN1) zur je- 
weilig zugeordneten, untergeordneten Funknetzwerk- 
kontrolleinheit (RNC1) lediglich ein einziger, gemein- 
samer Ubertragungspfad (GP11) aufgebaut wird. 

7. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass die mindestens eine 
Speichervorrichtung (SP1) im Funkkommunikations- 
system (FN2) zentral gefuhrt und verwaltet wird. 

8. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als Teilnehmergerat 
(UE1) jeweils ein Mobilfunkgerat. insbesondere Zellu- 
lanelefon, verwendet wird. 

9. Funkkommunikauonssystem (FN2) zum Verteilen 
cincr Gruppennachricht (GN1) an mindestens cine 
Gruppe (A) von Teilnehmergeraten, insbesondere nach 
einem der vorhergehenden Anspriiche, wobei minde- 
stens eine Speichervorrichtung (SP1) vorgesehen ist, in 
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der ein oder mehrcre TeiLnehmergeraie (UE1. UE2, 
UE4, UE5) der jeueiligen Gruppe (A) untcr cincr ge- 
meinsamen Ideniifizierungsadresse (IDA) ablegbar 
und dort fort lau fend aktualisierhar sind, wobei minde- 
stens ein Multicast -Center (MCO vorgesehen isU mil 5 
dessen Hilfe bei einem Veneilungswunsch eine neue 
Gruppennachricht (GN1) an die Mitglieds-Teilnehmer- 
gerate (UE1, UE2, UFA UE5) einer ausgewahlten 
Gruppe (A) auf einem gemeinsamen Ubertragungspfad 
(GP) an mindesiens eine ubergcordneie Funknetzwcrk- to 
kontrolleinheit (SGSN1) sendbar isu wobei die Spei- 
chervorrichtung (SP1) deran ausgebildet isu dass die 
akiuell zugehorigen, zu benachrichugenden Teilneh- 
mergerate (UE1, UE2, UFA UE5) dieser ausgewahlten 
Gruppe (A) ermittelbar, und diese der iibergeordneten 15 
Funknetzwerkkontrolleinheit (SGSN1) mitteilbar sind, 
und wobei die ubergeordnete Funknetzwerkkontroll- 
einheit (SGSN1) und/odcr ihrc jcwcilig in Wirkvcrbin- 
dung stehende untergeordnete Funknetzwerkkontroll- 
einheii (RNC1) derart ausgebildet sind, dass minde- 20 
stens ein Ubertragungspfad (UP11) von dieser iiberge- 
ordneten Funknetzwerkkontrolleinheit (SGSN1) zur 
Vencilung der Gruppennachricht (GN1) an die ermit- 
telten Milglieds-Teilnehmergerate (UE1, UE2. UFA 
UE5) bercitsLellbarisL 25 



Hierzu 26 Seite(n) Zeichnungen 



30 



35 



40 



45 



SO 



55 



60 



65 



100&4107A1J_> 



- Leerseite 



JSDOCID: <D£_10064107A1_I_> 



ZEICHNUNGEN 'SEfTE 1 



Nummer; 
Int CI. 7 : 

Off en I eg u n gstag : 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 



CO 
CD 
CD 



O 
CO 





CD 










MCC 


) 












T— CNJ 




LO 






O 

CNJ 


UJ LU 


LU 


LU 





CD CD 



U CNJ O 

i— CD 

=3 ^ V. 



CD 
CO 





i 
i 






\ 


co 


cm 






SGSN 


t 

i 


SGSN 




SGSN 











<< 




• • ■ 




Q 


O 















CO 



CO 
CD 
LO 



/ CNJ 
/ CD 
CNJ • 



OsJ 

CD 



CD 

LO 




CD 
CNJ 


CD 
QC 


• • • 


RNC 




CO 




CO 







CO 
CD 

QC 



CNJ 



CNJ 



CNJ 

CD 



CD 
QC 



^ CNJ 



CO 
CO 
GO 



co- 
co 



CNJ 
CNJ 
CO 
OQ 



* 

CNJ ' 

-CNj ; 

CNJ , 



1 1 

l V 



. CNJ 



t- \ CNJ 

CO CO 
CQ CQ 



<1 



CNJ 



N ) 



LO 
LU 



102 260/483 



;DOCI[> <DE_10064107A1_L> 



ZEICHNUNGEN SEITE 2 



Nummer; 
Int. CI. 7 ; 

Often I egu ngstag ; 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 



CD 
CO 



CO 
CD 
CD 



CD 



CO 




o 






Z3 / 






CD 








O 













> 


,'CD 
CNJ^ 


/I 


X 

X^ 


1 


CO 




CNJ 
















CO 




CO 




CO 


CD 




CD 




CD 


CO 




oo 




CO 


' CNJ 


✓ 


/ 


' i \ 



CZ> 
CNJ 



CO. 



CNJ 

o 
cc 



co 



CNJ 

o 
cc 



CO 

co' 



CNJ 



CD 



CO 
CO 
CQ 



CNJ 



cc 



* 

CNJ ' 

-CNI ; 

CNJ ; 



t X 



* 

.CNJ 



CQ 



i t— \ CNJ 

co ^~co 

. CQ CQ 




T 

CNJ 



>QWI 



sum 



s 



to / 

t-LJ / 



5DOCID: <DE_10064107A1 J_> 



102 260/483 



ZEICHNUNGEN SETTE 3 



Nummer: 
Int CI. 7 : 

Offenlegu ngstag: 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 




102 260/483 



SDOCID*<D£ 100&*107A1_1_> 



ZEICHNUNGEN SEITE 4 



Nummer: 
Int. CI. 7 : 

Offonlegungstag: 



DE 10064 107 A1* 
H04Q 7/20 

27. Juni 2002 




102 260/483 

SDOCID: <DE_I00B4107A1J_> 



ZEICHNUNGEN SEITE 5 



Nummer: 
Int CI. 7 : 

Offenlegungstag: 



DE 10064 107 A1 
H04Q 7/20 

27. Juni2002 




3DOCID: <DE_100&i107A1 J_; 



102 260/483 



ZEICHNUNGEN SEITE 6 



Nummer: 
tnt. CI. 7 : 

Offenlegu ngstag: 



DE100 64 107A1 
H04Q 7/20 
27. Juni2002 




SDOCID: <DE_10064107A1 J_> 



102 260/483 



ZEICHNUNGEN SEITE 7 



Nummer: 
Int CI. 7 : 

Off e n I egu n gstag : 



DE10064 107 A1 
H04Q 7/20 

27. Juni 2002 




102 260/483 



ZEICHIVIUNGEN SEITE 8 



Nummer: 
Int. CI. 7 : 

Often legungstag: 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 




102 260/483 

^DOCID' <DE 10064107A' ! > 



ZEICHNUNGEN SEITE 9 Nummer. DE 10064 107 A1 

Int. CI. 7 : H 04 Q 7/20 

Offenlegungstag: 27. Juni 2002 




sDOCID- <DE_100&4107A1_I 



102 260/483 



ZEICHNUNGEN SEfTE 10 



Nummer: 
Int. CI. 7 : 

Offentegungstag: 



DE 100 64 107 A1 
H 04 Q 7/20 

27. Juni 2002 




e DOCID <DE_ 1OO64107A1J > 



102 260/483 



ZEICHNUNGEN SEfTE 11 Nummer: DE 10064 107 A1 

Int. CI. 7 : H 04 Q 7/20 

Offenlegungstag: . 27. Juni 2002 




CD 



102 260/483 



ZEICHNUNGEN SEITE 12 



Nummor: 
Int CI. 7 : 

Offenlegungstag: 



DE10064 107A1 
H04Q 7/20 

27. Juni 2002 




3DOCIO' <DE 1006W107AT I > 



102 260/483 



ZEICHNUNGEN SEITE 13 



Numm8r: 
Int CI. 7 : 

Offenlegungstag: 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 




S3 



CO 



CD 
CO 



CD 

CO 

uS 



o 

QC 



CD 



cd 
-o 

iE 

CO 



o 
o 

o 
cc 
cc 



a> 
<5 

D 

cc 

CO 

c_> 
to 



X 
CP 

"£ 

o 
o 

"oo 
ro 

CD 



CO 



cu 

cc 

CO 



CO 

co 



X 

CO 



o 
O 

Tn 

CO 
CD 



a> 
"co 



+ 




o 


a5 


cx 


Nut 


a. 
=> 


<3 


aS 


MC- 


■o 

CO 

o 






CD 
"O 


cc 




CD 


a3 




rsi 














CO 


O 




!H 









co 

CO 

c= a> 
co = 



CD 



R St 

a? Z ^ 



S s 

CO Q. 



CO 

cd 
CO 



|1 

[CO CC. 



to , 

co 
"co 



co 
co 
CC 

co "=f* 
cd 

CZ CD 

•«5 

CO 

ia 



CO 



CO 



Jco »_ 
to i= 

CO 
CO 



^ CO I 

CO ^ I 

rtj CD I 

= ^ I 

3 I 

ZD CO 1 

IVI _Q I 

_ CD ' 

co ""^5 1 

CD CO I 

CO c 1 

o « ; 

T=> = 1 

CO C= I 

cc o 1 



CO w 
CD 

<c = 

co ^ 

CD w 
C5> CO 

§ s> 

CZJ> CO 
U= CD 

:co CO 
co ' 

CD _= 
CO 00 

- CD 



CD 
CD 

CD 

<C 
">< 

CD 
C= 

o 

"to 
co 
CD 



CD 

•1 



CD 
CO 



CO 
CO 

o 



CD 



O) 
CO 



CO 




CD 

o 



i_ — o 113 

23 5 



CO 



CD 



102 260/483 



'DOCID <Dr 1006-4107A1 I > 



ZEICHNUNGEN SEITE 14 



Nummer: 
Int CI. 7 : 

Off e n I eg u n gstag : 



DE100 64 107 A1 , 
H 04 Q 7/20 

27. Juni2O02 



O 
O 



CO 
CD 
CO 



CD 
CO 
CO 



CO 

"co 
Q 



CD 




CD 
CO 



O 
CD 



O 
i 

CC 
CC 



CL> 



CD 



cd 



CT5 



.92 



CD 
Q. 
Q_ 
ID 

CD 



CD Q 



cd 



CD 



2 S n 

LZi ^ ~E5 ^ 



JL 



CO 
CO 



CD 

cd 

CD 

cz 

CD 

Q_ 

Q_ 

CD 

"co 
ro 
O 



CD 

^ o 



o 



102 260/483 



SDOCID: <DE 1OOG4107A1_l_> 




102 260/483 



ZEICHNUNGEN SEITE 16 



Nummer: 
Int. CI. 7 : 

Offenlegungstag: 



DE10064107A1 • 
H 04 Q 7/20 

27. Juni2002 



FIG 16 



- IPR 



RQ 



I H1 I | H2 | pH3 



\ 

Hn^l 



t- 
T 



t 



Hn-1 Hn 



FIG 17 



IPR 



H1 



H2 H3 



J-RE 



Hn-2 



Hn-1 



Hn 



FIG 18 




102 260/483 



SDOCID: <DE_10064107A1_I_> 



ZEICHNUNGEN SEJTE 17 



Nummen 
Int CI. 7 : 

Offenlegungstag: 



DE 10064 107 A 1 
H04Q 7/20 

27. Juni 2002 



O 
O 



CO 

cd 

CO 



to 



ro 

CO 

Q 



CD 
"5 

o 



I 

O 



to 
a? 
•o 

d 
CD 

"53 



ET=> 9?;g 

"T co .52 cd 

UJ PO *— 03 

^ u X N 

... (13 Q) C 

= 8. 

*T= CD w 



O 



a> 

CD 



co 
UJ 



o 
"co 



CD 

-o 



o 



CD 

i 

o 



2r? 

CD 



O 

CD 

i 

CJ> 



o 
to 



CD 



O 
CO 



CO 



CD 

"CD 
CD 



CD 
O 



C3 



CD 

CO 



CD 

CO 



CO 
CD 



O 

o 

I 

O 
CO 

CNJ 



CD 

*a3 

CD) 
*u_ 
-O 

-£= 

CD 

a> 

O § 

t o_ 

UJ o. 

Q _t ? 







CD 




Q_ 




CD. 








<5 

i 






CD 




CD 




a> 






Q 


*0 




CD 


LU 


C3> 




ID 
r-sj 



X 
CD 

cr 
o 
CJ> 

O 



CD 
i 



C3> 



CO 
=5 

CO 



ca 
o 

LT5 



_CD 

o 



CD 
CD 



CO 



CD ~0 
=5 .2 




CD 
CD 



CO 

o 



o 



CD 

"83 

CD k — 

, . CD 

=== g-CC :CO 
LU ^ LU = 

= ^ -o r> 









CD 




C= 




o 








<£ 

CD 








*CD 







CD 
CD -o 

=5 o 



102 260/483 



ZEICHNUNGEN SEITE 18 



Nummer: 
Int CI. 7 : 

Off en I eg u ngstag : 



DE 10064 107 A1 - 
H04Q 7/20 

27. Juni 2002 








LU 
—J 






CO 






CD 










t . 








cr 




y i * 












o 


*q5 




"cr 


O) 




o 


:0 




CO 
LU 


CD 
CD 






=J 




CO 










CO 


cd 

CL 




1 cd 
LU "O 


2 






CD 


fo- 


UJ z 


CD 




=D DC 






CD 



o 

O 
i 

c <^> 
o> CC 

cr oc 
o 

'^=> cd 

*1 

CD CO 



CD 
CD "O 

=F5 o 



102 260/483 

3DOCID: <D£_t0064l07A1_l_> 



ZEICHNUNGEN SEfTE 19 



Nummer: 
Int CI. 7 : 

Offenlegungstag: 



DE 10064 107 A1 
H04Q 7/20 

27. Juni 2002 




102 260/483 



JDOCID; <DE lO084107A1_l_> 



ZEICHNUNGEN SEUE 20 



Nummer: 
Int CI. 7 : 

Off en I eg u ngstag : 



DE100 64 107A1* 
H04Q 7/20 

27. Juni2002 



O 
O 



GO 
CD 
GO 







CO 




CO 




-Q 




i 

rq 




CO 




CD 





1 

ZD 



CXI 

CD 



O 
CD 

ci 



CO 



.22 = 

.i I 

LU <C 



CO 



o 
CD 

I 

cd 
cc 
cc 



Q 
i 

CD 



a 

7* 



s 



o 

CD 

c_b 



CO 

























o 




^= 




oo 

LU 




ZD 




oo 




TO 








I CD 




UJ -o 








So 




UJ ^ 




ZD CC 














CO 




LU 
ZD 








. /oo 

Q S3 






s~ 


Info: 


LU <C 
ZD CC 



r-sl 

_o 

C3> 
CO 
GO 
OO 
03 



cc 

oo 



O 



t 

Q_ 
=3 
O 

cp 

CD 
LO 



CO Q_ 

=§ = 

03 CD 
CC i 
• CD 





CO 
LU 




ZD 


Oi 


t 


C 




a. 


Q. 


CD- 


=3 


CO 


O 




CD 




i 

CD 







+ 

» 



CD 



03 CD 

s & 

"S CD 





?CO 


cx 






o 




*3 

CO 
LU 


C-Gi 




ZD 




f 

LU 


CO 


a3 

"O 




a5 


CO 
LU 


LU 


*o 


zz^ 








Info 


RA, 


cz 





c: 




o 




"o 




CO 








c: 




o 




O 


cz 


i 

CD 


<r> 


cc 


c= 


CC 


o 






CO 


^2 


-a 


<C 


=3 


CD 


CO 




JQ 









102 260/483 



SDCCID: <DE_1O064107A1_L> 



ZEICHNUNGEN 5EITE 21 



Nummen 
InL CI. 7 : 

Offenlegungstag: 



DE 10064 107 A1 
H04Q 7/20 
27. Juni 2002 



03 
=5 o 




> 






-a 


> 






CO 
U_l 










iect 




"O 
O 




^> 


■a 
o 


















Co 








V 





CO 
CM 

CD 



102 260/483 



JOOCia <DE_1 00641 07A1J_> 



2EICHNUNGEN SEITE 22 



Nummer: 
Int. CI. 7 : 

Offenlegungstag: 



DE 10064 107 AI, 
H04Q 7/20 

27. Juni 2002 



o 




CO 










f ^\ 
\SJ 




QJ> 








CT 




CO 








1 ^ 
O) 




oo 




1 




CO 










co 




CD 




CO 






CO 

cc 



CO 
CO 



CD 

cc 

CO 



CNJ 



OO 

CC 
CD 
CO 

CO 



CD CD 

"~ CO 

=0 — 



CD 



CO 



O) O- 
rsj o 

+ <s 

CO i 



CD 

i 

O 



CD 
"O 




co 



CD 

cz 

CO 



CD 
CO 

i 

CO 

cc 

+ 



CD 
CD 



o 

CO 
I 

co 
cc 
cc 



CO 



CD 

"cd 

CO 



o 
cd 

CD 

CZ 
CO 

"co 

CD 

13 , 

cr 

CD 

cc 
i 

O) 
CO 



CO 



CO 



CD 

CO 

CD 

CC 



CD 

co 



CO 
-O 



CO 

CD 

CO 

co 



o 
cd 



o 
O 

2 e 

;s 

O Q 
\ i 
CC CO 

o ^ 
o_5S 













55 


ex. 


O 


o 


*CD 


<5 

1 


a 




CD 


o 






o 


CD 


no 


CD 






co 


efo 


UJ 
Z3 


CD 


CO 




CO 


I 


o 


CO 








cc 



CO 
CD 
CO 

o 
a. 

CD 

co 

CD 

CO 
CO 



H CD 
o • 

S CD 



CD 

cz 

CO 

eh 

CO 



CO 



CD 

I 

CO 



CO 

CO 
CD 
CO 



CD 

to 

CO 



co 
i 

CO 



CD 

co 

CD 
GO 

CO 



CD O 

•coO 
a5 S=2 



CD 
CO 

"rsj 

CD 
O- 

co 
t 



CD 

CO 
CD 
CO 



co 
CC 



CO 
CD 

CO 
CD 
GO 

CO 



co 



CD 
"CO 



co 
i 

CO 



oo 



a. 

O 

CD 

i 

CO 




/ — 


TO 




CO 


CD 




UJ 

33 

CD 


nnect 


Mode 


"co 
V 


Co 





102 260/483 



SDOCID: <DE_10084107Al_U> 



ZE1CHN4JNGEN SEfTE 23 



Nummer: 
Int CI. 7 : 

Offenlegungstag: 



DE 10O64107A1 
H04Q 7/20 

27. Juni 2002 




□C 



CO 
CD 

CT 
CD 
CC 
i_ 

O) 

CO 

s 

I 

O 



CO 

<C 
CC 

CD 
"O 

CO 



CD CD 
CO 



CD 



«^» O 

+ CD 

CO I 
LU O 



O 

c5 
ci 



CD 
TD 

O) 
.£= 

CO 



CD 

CO 
i 

CO 

cc 

+ 



o 

CD 



o 
O 

ci 
or 
cc 



CO 



CD 

O 
CD 



O 
O 

c= 
co 

"oo 

CD 



CD 

CC 
I 

CO 



I 

o 



CD 
CO 
I 

CO 

cc 



CD 
CO 



CD 

CO 
CD 
CO 

CO 



O CD 

CT»S 
CO 

S Q 

+ 9S 





Q 




i 








CO 


O CD 


cp 


co^ 


CO 


-IDs 


o 


CJ 






c 


cc 



CO 
CD 

CO — 
CD f>* 

s s. 

ci " 

a. a5 

ji-s 

S CO 



CO 



CD 

CO 
CD 

CO 

I 

o 



o 



o 

CJ> ^ 

si 

TO 

gci 

+ s - 

S T 
CC CJ> 



o 

CD 

ci 



.CD 
*oo 
cz 

CO 



CO 



O 



co 
CJ> 

CC 

CO 

CO 
CD 
CD 

CD 



CO 
GO 



CD 



CD 

CO 
CD 

CO 



cn 



cc 



CO 
CD 

co 

CD 
CO 
I 

o 



CD 



CO 



cp 
"co 
=> 

OS 
CO 

s 

o 



o 

CD 
i 

O 



CD 
CD -o 



<D 

— O « 

J* £ O 

.22. 

o 
O 



C\J 

CD 



CD 
TD 
O 

CD JD 
CD "O 
X3 CD 
CZ 

e 
o 
o 



r 


-o 




le UEs: 


CD 




nnect 


Mode 


CO 


Co 





102 260/483 



SDOCID: <DE_100ft*107A1_l_> 



ZEICHNUNGEN SEITE 24 



Nummer; 
Int. CI. 7 : 

Offenlegungstag: 



DE100 64 107A1* 
H04Q 7/20 

27. Juni 2002 





CD 

"O 
05 

CO 



"op 

CO 
I 

CO 
QC 

+ 



o 

I 



CO 



a> 



o 
o 

CD 

C= 
CO 

"go 
cd 



o 
QC 

OS 
CO 



i 



LO 




TO 


-cr 
o 


on 


a? 
o_ 

GO 






Mapping: 
lU-Bearer 





CD 




"to 


RB-Setup 


-Transfer an 


.evil. 


OS 
CO 


co i ; 


8. MC- 



CO 

> S 

!<= 

i- CL> 
: -£? 

Q_ CD 
=» O) 
O => 
k— rsi 

CD ^ 

1 CD 



o3 r ~ 



CD 



O 

o 



r 


T3 


N 


CO 


CD 




22 


O 
CD 


ipo 


CD 
-Q 


oni 






CJ) 


> 


\ 



. . "O 

go 03 

CD 



o .g 

= 1 



102 260/483 

SDOCID: <DE_10064107A1_L> 



ZEICHNUNGEN-SEfTC 25 



Nummen 
Int CI. 7 : 

Offenlegungstag: 



DE10064 107A1 
H04Q 7/20 

27. Juni 2002 




CD 

cc 



CO 

a> 
Z3 
cr 

CD 



CT1 
CO 



cd 



CSJ 



CO 

cc 
cd 

CO 
CD 

cc 

CD Q3 

1 = 

CD ro 
0> Q. 
Z3 Z3 

is 5 



CO- 
ZD 
O 

C3 
i 

O 

cd 
■a 

CO 



CO 
U-I 

=> 

a5 
*o 
o 

CD 
CO 



CD 

GO 

t 

CO 

cc 

+ 



o 
cp 

CD 
CC 



CO 



o 

CD 
CD 
""O 

CO 

to 

CD 



CD 
CC 
I 

cn 

CO 

i 

CD 



LO 



CD 

CO 
I 

CO 

cc 



a> 

CO 



:£ 
=3 
<£ 

ra 

CD 
CO 





a. 






E 


Gro 


*H cd 


Co 






q" 






CO 


LU 




ID 


CD o 




i 


+ 


ON 


LU 
ZD 


cc. 



c=l 




ZD 




o 




c5 
i 


are 


CD 


-Be 


a? 








CD 


t 




CO 


efo 


LU 
ID 


cm 


co 




ra 


i 


o 


O 


*cz 






CC 




C75 CD 

Q. CD 
CXCO 
CO i 



CD 

"co 

d 

co 

CD 
"to 
(= 
co 



O) 

CO 



CD 



CO 

,-^CD 
co ^ 

LU cc 

= o> 

C= 'CI 
j — :0 

Q_ CD 

ZD CZB 

2 3 
CD _ 
i cd 
CD -Q 



CD 
CD TZ> 



-i-I CO 

r-«j cd 



CD 

o 



o 
cd 



OsJ 

CD 



CD 

o 

CO 

~ TZ3 

CD aa 

CD CD 
-O CD 



O 
CD 



CO 



CD 

-a 
o 



102 260/483 



SDOCID: <DE_10064107A1J_> 



ZEICHNUNGEN SEITE 26 



Nummer: 
Int. CI. 7 : 

Offeniegungstag: 



DE100 64107A1 ' 
H04Q 7/20 

27. Juni2002 




co 
a> 



cc 
i 

o> 

CO 



3 

OC 



CO 

CJ> 
CC 

CD 

a3 to 

=3 =3 
r-j o 

+ c5 

CO i 

U_l o 



CD 
i 

O 



CD 




CD 
CO 



CD 
CO 
I 

GO 
DC 

+ 



CO 
CD 



O 

o 

I 

o 
cc 
cc 



CD 
CD 



O 

o 

CD 



CO 

"co 

CD 

u , 
cr 

CD 

CC 

CD 

co 
i 

O 



in 



CD 

CO 
I 

CO 

cc 



CD 
CO 



CO 
CD 
CO 

GO 



CD 

c« 

CD 
CO 
I 



c= <5 

O ' 
CD - 

+ e> 




c 2 

O CD 

o » 

■-i 

I I 



+ q" 

lu ~T 
=5 CJ> 



CD 
15 



CO 



ra 

CD 



:0 



CO 

=? 2 

O CD 



CD 



CD 
O -Q 



-a 

CO 
rsj CD 

Si 

o 
o 



CD 
"O 

o 



CD 

o 

CO 

CD CD 

CD O 
-Q CD 

cr 
cr 
o 



go .22 ^ 
i_u tS £2 
=> £ o 



102 260/483 

ISDOCID; <0E_1 00641 07A1_I_> 



